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Abstract : This  is  a report  of  the  results  that  have  been  obtained 

from  a research  project  aimed  at  learning  methodologies  and 
developing  tools  useful  for  obtaining  reliable  software  of  the 
Fault-Tolerant  Spaceborne  Computer  (FTSC).  Results  are  divided  in 
three  areas.  First,  a study  was  performed  on  the  methods  of 
designing  well-structured  recovery  programs  which  are  invoked  on 
detection  of  an  error  to  recover  an  operational  system  configuration 
and  a consistent  computation  state . This  study  involved  the 
experimental  development  of  an  FTSC  recovery  program.  This  report 
discusses  several  program  design  and  system  recovery  strategies  that 
have  been  found  useful  in  obtaining  an  easily  understandable  recovery 

\ 

program,  together  with  the  program  developed.  Second,  a language 

/ 

processor  was  developed  to  facilitate  experimenting  with  recovery 
block  which  is  a language  construct  designed  to  support  structured 
incorporation  of  program  redundancy.  It  translates  programs  written 
in  PASCAL  augmented  with  recovery  block  into  equivalent  programs  in 
ordinary  PASCAL.  The  translation  strategy  used  and  the  organization 
of  the  translator  are  described.  Third,  a new  approach  to  error 
recovery  in  distributed  systems  of  cooperating  parallel  processes  was 
developed  In  such  systems  processes  must  cooperate  in  recovery.  In 
contrast  to  the  previously  studied  approaches  that  require  the 
program  designer  to  coordinate  the  recovery  point  specifications  of 
processes,  the  new  approach  relieves  the  programmer  of  that  burden  by 
using  an  intelligent  processor  system.  Methods  for  efficient 
implementation  of  such  a processor  system  were  also  developed. 
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Introduction 


This  is  a report  of  the  results  that  have  been  obtained  from  a 
research  project  carried  out  at  University  of  Southern  California 
under  the  sponsorship  of  U.S.  Air  Force  - SAMSO  during  July  1,  1977 
- August  31,  1978.  The  project  aimed  at  learning  methodologies  and 
developing  tools  useful  for  obtaining  reliable  software  of  the  FTSC. 
More  specifically,  research  efforts  were  directed  in  three 
directions . 

(1)  to  study  the  effective  ways  of  designing  well-structured  and 
fault-tolerant  recovery  programs.  (Recovery  programs  are  the 
programs  which  are  /Evoked,  on  detection  of  an  error,  to  recover  an 
operational  system  configuration  and  resurrect  the  interrupted 
computation.)  Also  to  study  the  effective  ways  of  using  design 
redundancy  to  obtain  fault-tolerant  programs  (i.e.,  programs  capable 
of  tolerating  some  residual  design  errors  in  them) . 

(2)  to  develop  a language  processor  to  facilitate  structured 
fault-tolerant  programming. 

(3)  to  study  the  structure  of  fault-tolerant  distributed  systems. 

The  results  are  described  in  three  parts,  following  this  section. 

Part  I describes  some  program  design  and  system  recovery 
strategies  that  have  been  found  useful  in  obtaining  an  easily 
understandable  recovery  program  of  the  FTSC.  The  strategies  are  of 
such  general  nature  that  they  can  be  useful  in  designing  recovery 
programs  of  other  modular  fault-tolerant  computers.  It  also  presents 
a PASCAL  specification  of  a FTSC  recovery  program  that  has  resulted 
from  the  application  of  the  strategies. 
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Part  II  documents  a language  processor  that  translates  programs 
written  In  PASCAL  augmented  with  recovery  block  into  equivalent 
programs  In  ordinary  PASCAL.  The  recovery  block  facilitates 


i 
I 
♦ 

structured  incorporation  of  program  redundancy.  The  basic 

< 

translation  strategy  is  discussed  and  then  the  full  listing  of  the 

J 

translator  is  given  together  with  some  test-run  results. 

Part  III  discusses  a new  approach  to  error  recovery  in 

distributed  systems  of  cooperating  parallel  processes.  More 
specifically  when  each  process  is  capable  of  error  detection, 

rollback,  and  retry,  the  recovery  points  of  the  processes  must  be 

properly  coordinated  to  prevent  a disastrous  avalanche  of  process 
rollbacks.  In  contrast  to  the  previously  studied  approaches  that 
require  the  program  designer  to  coordinate  the  recovery  point 
specifications  of  processes,  an  approach  of  relieving  the  programmer 
of  that  burden  was  developed.  The  new  approach  relies  upon  an 
intelligent  processor  system  (that  runs  processes).  Basic  rules  of 
reducing  storage  and  time  overhead  in  such  a processor  system  were 
also  developed. 
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Abstract : This  paper  reports  the  results  obtained  in  an  experimental 
project  aimed  at  developing  a well-structured  and  effective  recovery 
program  of  the  FTSC  (Fault-Tolerant  Spaceborne  Computer).  This 
experiment  was  also  chosen  as  a means  of  studying  the  ways  of  using 
design/program  redundancy  to  improve  the  software  reliability,  mainly 
because  of  the  relatively  small  program  size  and  the  unusual 
complexity  in  analyzing  the  situations  that  the  recovery  program  must 
deal  with.  The  paper  presents  several  program  design  and  system 
recovery  strategies  ?"hdt  have  been  found  to  be  useful  in  obtaining  an 
easily  understandable  recovery  program  of  the  FTSC  but  may  also  be 
useful  in  development  of  recovery  programs  of  other  computers.  It 
then  discusses  a recovery  program  for  the  FTSC  that  has  resulted  from 
the  application  of  the  strategies.  The  recovery  program  has  been 
specified  in  PASCAL  and  its  conversion  into  an  assembly  language 
program  is  briefly  discussed.  The  listing  of  the  PASCAL  specification 
is  given  in  an  appendix. 
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1 . Introduction 


This  is  a report  of  the  results  obtained  In  a research  project 
that  involved  the  development  of  a program  of  the  FTSC 
(Fault-Tolerant  Spaceborne  Computer)  [B1,S1,S2]  responsible  for 
recovering  an  operational  system  configuration  and  resurrecting  the 
interrupted  computation.  The  project  was  launched  with  two  major 
objectives: 

(1)  to  identify  good  structures  and  design  strategies  for  the 
software  that  controls  recovery  from  hardware  faults,  and 

(2)  to  find  effective  ways  of  using  design/program  redundancy  in 
development  and  maintenance  of  robust  real-time  software; 

First,  the  systems  employed  in  critical  applications  requiring 
ultra-reliability  commonly  contain  large  amounts  of  redundant 
hardware.  The  redundant  hardware  is  provided  primarily  to  facilitate 
fault  detection  and  recovery.  Recovery,  following  the  fault 
detection,  is  typically  a function  of  both  hardware  and  a special 
software  called  recovery  program.  The  hardware  automatically 
recovers  certain  modules,  collectively  called  a hardcore . needed  for 
correctly  running  a recovery  program,  and  then  the  recovery  program 
recovers  additional  hardware  modules,  establishes  an  operational 
configuration,  and  recovers  the  information  needed  to  resurrect  the 
interrupted  computation.  The  performance  of  a recovery  program  is 
crucial  to  the  success  of  the  entire  application  requiring  ultra- 
reliability. A recovery  program  must  be  both  efficient  and  reliable 
itself.  Also  during  the  design  of  a recovery  program,  considerations 
must  be  given  to  the  possible  faults  of  the  hardware  modules  on  which 
the  recovery  program  runs,  i.e.,  the  CPU  and  the  memory  containing 
the  recovery  program.  The  redundant  hardware  performing  fault 
detection  may  also  be  faulty.  Engineering  an  efficient  and  robust 
recovery  program  is  thus  unusually  complex.  In  spite  of  the 
important  role  that  a recovery  program  plays  in  any  fault-tolerant 
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system,  very  little  has  been  published  in  this  field  and  many 
fundamental  questions  concerning  good  structures  and  design 
strategies  of  a recovery  program  have  yet  to  be  answered. 

Secondly,  the  study  of  the  methods  of  using  program  redundancy, 
frequently  called  fault-tolerant  programming,  was  motivated  by  its 
potential  as  a means  of  tolerating  residual  design 
errors/inadequacies  [HI , H2, K1 , R1 ] . In  spite  of  recent  advances  in 
rigorous  specification,  structured  design,  program  validation,  and 
development  of  modern  high  level  languages,  large-scale  software  is 
still  put  into  operation  with  residual  design  errors/inadequacies. 
Thus  fault-tolerant  programming  appears  to  be  an  attractive 
supplement  to  those  already  widely  accepted  practices  for  the 
development  of  real-time  software  required  to  be  ultra-reliabe . In 
particular,  a language  construct,  called  reooverv  block,  developed  by 
Horning  et  al  [H3.R1]  supports  the  incorporation  of  program 
redundancy  in  a well-structured  form.  It  thus  paved  a way  to 
extensive  use  of  program  redundancy  without  degrading  the  program 
readability  and  provided  a further  stimulus  to  the  initiation  of  this 
study.  Appendix  A briefly  summarizes  the  syntax  and  semantics  of  the 
recovery  block. 

As  a means  of  identifying  problem  areas  and  testing  various 
potential  solutions,  the  design  of  a recovery  program  of  the  FTSC  was 
chosen.  A recovery  program  of  the  FTSC  was  considered  to  be  an  ideal 
subject  of  a fault-tolerant  programming  experiment  (in  addition  to 
being  an  obvious  subject  of  a recovery  program  engineering 
experiment),  due  to  the  relatively  small  program  size  and  the  unusual 
complexity  of  the  situations  that  the  recovery  program  must  deal 
with.  In  addition,  the  FTSC  is  a modular  computer  equipped  with  a 
powerful  set  of  hardware  features  supporting  fault  detection  and 
recovery  [S1,S2].  This  rich  set  of  fault-tolerant  hardware  features 
offers  a number  of  options  in  designing  a recovery  program,  thereby 
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providing  ample  opportunities  for  employing  recovery  blocks  with 
benefits.  That  is,  the  primary  recovery  procedure,  alternate 
recovery  procedures,  and  the  acceptance  test  can  use  independent  test 
and  configuration  techniques.  Therefore,  although  a conventionally 
structured  recovery  program  has  operated  satisfactorily  on  the 
brassboard  FTSC,  an  experimental  development  has  been  undertaken 
under  the  sponsorship  of  the  U.S.  Air  Force  - SAMSO  to  study  the 
application  of  fault- tolerant  programming  techniques  to  such  a 
program.  The  recovery  block  provides  a means  of  incorporating 
multiple  recovery  procedures  in  a well-structured  form,  but  the 
individual  procedures  must  also  be  systematically  designed  and  easy 
to  understand  to  increase  the  chance  of  obtaining  a robust  recovery 
program.  This  requirement,  although  not  furthur  discussed  here,  was 
also  implemented  in  the  resulting  program. 

Although  the  FTSC  has  been  documented  fully  in  [F1,S1,S2],  we 
have  included  a sketch  of  its  features  to  make  this  report  self- 
contained.  Section  3 discusses  the  adopted  organization  of  the 
design  process.  Several  basic  design  strategies  that  have  been  found 
to  be  useful  in  obtaining  an  easily  understandable  recovery  program 
are  discussed  in  section  4.  Section  5 describes  a model  of  the  FTSC 
devised  to  support  the  development  of  a systematic  recovery 
procedure.  The  procedure  obtained  is  discussed  in  section  6. 
Section  7 provides  a brief  introduction  to  the  PASCAL  specification 
and  section  8 briefly  discusses  the  aspect  of  converting  the  PASCAL 
specification  into  an  assembly  language  program.  Appendix  B contains 
a complete  recovery  program  specified  in  PASCAL  (augmented  with 
recovery  blocks).  Appendix  C supplements  the  PASCAL  specification  in 
Appendix  B with  more  details  on  some  subprocedures  of  testing 
modules . 
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2 . A sketch  of  the  FTSC  structure 


The  FTSC  is  a 32-bit  microprogrammable  machine  designed  to 
operate  in  long-duration  space  missions  through  radiation  and 
spacecraft  discharge  events.  It  is  intended  to  provide  a five-year 
on-orbit  capability  with  95%  probability  of  survival  [B1,S1].  Figure 
1 depicts  the  configuration  of  the  FTSC.  Every  functional  unit 
(shown  in  Figure  1)  contains  a certain  amount  of  hardware  redundancy. 
Each  unit  is  briefly  described  below  and  many  features  irrelevant  to 
fault  detection  and  recovery  are  not  described. 

2.1  Configuration  control  unit  (CCU) 

The  FTSC  contains  more  CPU  modules  and  lines  on  the  address  and 
data  buses  than  required  by  an  operational  system  configuration. 
Selection  of  a subset  of  those  components  to  form  an  operational  (CPU 
- bus)  configuration  is  a function  of  the  CCU.  In  addition,  the  CCU 
receives  reports  from  the  fault  detectors,  also  called  monitors . 
distributed  throughout  various  functional  units  (shown  in  Figure  1). 
For  example,  each  module  that  uses  the  address  bus  (A-bus)  and/or 
data  bus  (D-bus)  contains  a bus  code  monitor  which  detects  invalid 
codes  on  the  bus.  When  a fault  is  detected  by  one  or  more  functional 
units  (more  precisely  the  monitors  contained  in  them),  the  condition 
is  reported  to  the  CCU.  Upon  receiving  fault  reports  the  CCU 
categorizes  the  faulty  situation,  establishes  a new  CPU-bus 
configuration  if  the  performance  of  the  present  configuration  is  in 
doubt,  and  then  forces  the  CPU  to  execute  the  recovery  program 
through  an  interrupt  called  fault  interrupt.  Throughout  the 
execution  of  the  recovery  program  the  categorized  information  on  the 
detected  fault  is  supplied  to  the  CPU.  The  fault  categorization 
scheme  used  by  the  CCU  is  described  at  the  end  of  this  section.  The 
CCU  is  clearly  a hardcore  unit  of  the  FTSC  and  is  TMR-  (triple 
modular  redundancy)  configured. 


vivo  Mom  vivo  ir.mi 


Figure  i.  FTSC  Block  Diagram 


2.2  Central  processing  unit  (CPU) 
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The  system  contains  four  CPU  modules  and  has  two  of  them  powered 
on  at  any  one  time,  one  called  active  CPU  (A-CPU)  and  the  other 
called  monitor  CPU  (M-CPU).  As  mentioned  above,  selection  of  two 
lowered  CPU  modules  is  a function  of  the  CCU.  Both  the  active  and 
monitor  CPUs  always  execute  the  same  program  but  in  different  ways. 
While  the  active  CPU  interacts  with  other  modules  in  the  system 
hrough  the  buses  during  program  execution,  the  monitor  CPU  compares 
the  information  loaded  onto  the  buses  by  the  active  CPU  with  the 
result  of  its  own  execution  of  the  same  program  and  reports  a 
disagreement,  if  occurs,  to  the  CCU. 


A CPU  module  is  microprogram-controlled  and  contains  8 general 
purpose  registers.  The  CPU  uses  16-bit  (or  2-byte)  addresses  and 
acknowledges  10  levels  of  interrupts.  Besides  the  ROM  containing  the 
microprogram,  the  CPU  contains  another  ROM,  called  reconfiguration 
ROM,  which  contains  a recovery  program  (to  be  exact,  an  initially 
executed  segment  of  a recovery  program) . This  reconfiguration  ROM  is 
a CPU-resident  part  of  the  memory  addressed  by  the  16-bit  addresses. 
Therefore,  the  system  contains  four  copies  of  (a  segment  of)  the 
recovery  program  distributed  among  four  CPUs.  In  addition,  a CPU 
contains  a pair  of  special  registers,  called  hardware  status  word 
1 HSW)  registers  and  denoted  by  HSW1  and  HSW2,  carrying  information  on 
system  status  (i.e.,  the  current  CPU  and  bus  configurations,  the  most 
' eeently  reported  fault,  etc)  partly  supplied  by  the  CCU. 


The  instruction  set  of  the  FTSC  supports  32-bit  fixed-point  and 
floating-point  arithmetic  as  well  as  vector  operations  that  are 
particularly  useful  for  navigation  and  pointing  applications.  Direct 
and  indirect  addressing  with  predecrement  and  post  increment  are 
available.  Some  instructions  are  specifically  oriented  for  testing 
the  fault-tolerant  features.  For  example,  data  words  can  be  stored 
with  bad  parity  in  order  to  exercise  error-detection  and  correction 
features  in  the  main  memory  unit  (MMU)  modules.  Some  instructions 
are  designed  to  be  executed  differently  by  the  A-CPU  than  by  the 
M-CPU.  Such  instructions  can  thus  be  used  to  cause  disagreement 
between  the  two  operational  CPUs. 


There  are  instructions  for  powering  on/off  the  DMA,  SIU,  and  MMU 
modules.  There  are  also  instructions,  which  may  be  called  CCU 
commands  (these  are  called  "program  flags"  in  [SI]),  by  which  the  CPU 
can  cause  the  CCU  to  change  its  state  and  thereby  change  the  system 
configuration  (including  the  selection  of  CPU  modules  and  bus  lines 
to  be  used ) . 


2.3  Main  memory  unit  (MMU) 

The  MMU  can  cq^ist  of  up  to  24  non-volatile  and  non-destructive 
readout  memory  modules,  each  containing  4K  words.  As  many  as  15 
modules  can  be  powered  on  at  any  one  time,  with  each  identified  by  a 
changeable,  but  unique,  four-bit  soft  (module)  name.  A properly 
functioning  memory  module  responds  to  all  addresses  whose  four  most 
significant  bits  correspond  to  the  current  soft  name  of  the  module. 
On  the  other  hand,  each  module  can  be  accessed  by  a permanent  and 
unique  module  number,  called  hard  name,  for  the  purpose  of  powering 
on/off,  assigning  a new  soft  name,  etc. 
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An  MMU  module  contains  41  bit  lines  of  which  32  are  used  to 
contain  data  Information,  6 to  carry  parity  codes  for  error  detection 
and  correction,  and  3 as  spare  bit  lines.  Therefore,  up  to  three  bit 
lines  may  be  lost  without  disabling  the  module  and  the  information 
contained  in  a module  can  be  recovered  and  saved  into  another  module 
as  long  as  the  number  of  lost  bit  lines  does  not  exceed  four. 

2.4  Two  direct  memory  access  (DMA)  units 

Two  DMA  functional  units  DMA1  and  DMA2 , are  provided.  Each  is 
redundant,  consisting  of  a pair  of  modules  of  whioh  one  is  powered  on 
at  any  one  time.  Each  DMA  function  provides  a direct  parallel  access 
between  an  external  user  (i.e.,  peripheral  equipment)  and  the  MMU. 

2.5  Serial  interface  unit  (SIU) 

The  dual  redundant  SIU  functions  much  the  same  way  as  the  DMA 
but  provides  serial  acee**-  for  up  to  sixty  users.  Only  one  SIU 
module  is  normally  powered  on  at  any  one  time. 

2.6  Power  unit  (PU) 

The  power  supply  of  the  FTSC  is  provided  by  the  redundant  PU 
that  consists  of  two  modules,  each  containing  dual  output  (voltage) 
monitors.  If  either  monitor  finds  a (voltage)  out-of-tolerance 
condition,  it  immediately  announces  this  condition  to  the  rest  of  the 
system  and  effects  a switchover  to  the  alternate  module.  Therefore, 
the  PU  is  an  automatically  recovering  unit. 
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2.7  Timing  unit  (TU) 
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The  TU  supplies  clock  pulses  to  the  rest  of  the  system  and 

i 

consists  of  two  modules,  each  containing  dual  output  monitors.  As 
with  the  power  monitors,  either  monitor  can  cause  a switchover  to  the 
alternate  module.  Again,  the  TU  is  an  automatically  recovering  unit. 

2.8  Circumvention  unit  (CU) 

This  TMR-conf igured  unit  detects  radiation  events  and  (upon 
detection)  clamps  other  units  in  the  system  until  the  radiation 
disappears,  thereby  protecting  them  from  possible  damage. 

2.9  Hardened  timer  (HT) 

The  HT  is  used  to  count  the  amount  of  elapsed  time  during  the 
periods  of  PU  failure  or  high  radiation  event.  It  is  TMR-conf igured . 

2.10  Bus  network 

There  are  seven  buses.  The  A-bus  (carrying  16-bit  addresses) 
and  the  D-bus  (carrying  32-bit  data  words)  use  cyclic 
error-correcting  codes  with  8 parity  bits  (i.e.,  1 parity  code  byte) 
and  contain  one  spare  byte  each.  Thus  the  A-bus  consists  of  four 
bytes  of  lines  and  the  D-bus  consists  of  six  bytes  of  lines.  As 
mentioned  earlier,  selection  of  the  bytes  to  be  used  is  performed  by 
the  CCU,  and  the  CPU  can  also  cause  the  CCU  to  reconfigure  the  A-/D- 
bus  by  executing  a CCU  command.  In  addition,  there  are  the  control 
bus  (C-bus)  used  in  conjunction  with  the  A-  and  D-  buses,  the 
interrupt  bus  (I-bus)  carrying  interrupt  signals,  the  status  bus 
(S-bus)  carrying  fault  reports  and  reconfiguration  signals,  etc. 
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2.11  Additional  details  on  the  CCU 


Each  time  a CCU  command  for  reconfiguring  the  CPU,  the  A-bus,  or 
the  D-bus  is  executed,  the  new  subset  of  components  is  chosen  such 
that  the  same  subset  is  not  repeated  until  all  subsets  have  been 
tried.  There  are  a number  of  different  states,  where  the  CCU 
establish  different  system  configurations,  that  the  CCU  can  be  in. 
To  be  more  specific,  the  CCU  can  be  viewed  as  containing  five 

flip-flops : 

the  first  called  reconfiguration  state  flag. 

the  second  called  alexic  state  flag. 

the  third  called  flag  1 . 

the  fourth  called  flag  2.  and 

the  fifth  called  flag 

There  is  a CCU  command  by  which  the  CPU  oan  clear  all  five  flags  at 
once.  These  flags  are  used  as  follows. 

(1)  The  reconfiguration  flag  is  set  (i.e.,  the  CCU  enters  a 

reconfiguration  state)  when  a fault  interrupt  is  generated  by  the  CCU 
(after  receiving  a fault  report  in  a normal  state). 

(2)  On  receiving  a report  of  a PU  failure  or  high  radiation  event, 

the  CCU  enters  an  alexic  state  (by  setting  the  alexic  flag)  and  this 

state  transition  causes  a signal  to  be  generated  for  turning  off  the 

DMA,  SIU,  and  MMU  modules. 


(3)  Flag  1,  flag  2,  and  flag  3 can  be  set  only  by  execution  of  a CCU 
command  (by  the  CPU).  When  flag  1 is  not  set  while  the  CCU  is  in  a 
reconfiguration  state,  the  DMA,  SIU,  and  MMU  modules  shall  not 
respond  to  any  address  on  the  A-bus.  By  setting  flag  1 the  recovery 
program  can  enable  the  modules  to  respond  to  their  addresses  and  will 
do  this  at  its  convenience.  In  fact,  flag  1 was  provided  primarily 
to  enable  CPU  and  bus  tests  without  affecting  the  DMA,  SIU,  and  MMU 
modules.  Thus  flag  1 can  be  used  to  indicate  that  the  CPU  has  been 
validated.  Flag  1 can  be  reset  in  three  different  ways:  PU  failure 
or  high  radiation  event,  CPU  reconfiguration  due  to  detection  of  a 
CPU  fault,  or  execution  of  a CCU  command. 

(4)  Flag  2,  when  set,  inhibits  CPU  reconfiguration  and  generation  of 
fault  interrupts  due  to  various  faults  except  PU  failure,  high 
radiation  events,  and  TU  reconfiguration  (i.e.,  automatic  module 
switchover).  Flag  2 is  reset  on  detection  of  any  fault  and  can  also 
be  reset  by  execution  of  a CCU  command. 

(5)  Flag  3,  when  set,  inhibits  generation  of  fault  interrupts  caused 
by  the  reports  implicating  the  A-bus,  D-bus,  DMAs,  SIU,  or  MMU.  Flag 
3 is  reset  on  detection  of  any  fault  and  can  also  be  reset  by 
execution  of  a CCU  command. 

The  fault  categorization  scheme  used  in  the  CCU  is  the 
following . 

Cat  I:  PU  failure  or  detection  of  radioactive  events  by  the  CU, 

Cat  II:  CPU  implicated  (e.g.,  disagreement  between  A-  and  M-  CPUs), 

Cat  Ilia:  A-bus  implicated  (e.g.,  detection  of  an  invalid  code  on 
the  A-bus  by  more  than  one  bus  code  monitors), 

Cat  Illb:  D-bus  implicated, 

Cat  IV-DMA1 : DMA  1 implicated  (i.e.,  the  DMA1  is  the  only  unit  that 
detected  an  Invalid  code  on  one  of  the  buses), 


IV-DMA2:  DMA2  implicated, 

| 

IV-SIU:  SIU  implicated, 

IV-overrun:  An  MMU,  DMA,  or  SIU  module  has  not  responded  to  a 

i 

request  within  the  predetermined  period, 

i 

IV-TU:  TU  reconfiguration  (i.e.,  switchover)  has  occurred. 

While  the  system  is  in  a reconfiguration  3tate,  the  CCU  supplies  the 
category  information  about  the  most  recently  reported  fault  to  the 
CPU  (to  be  exact,  to  a field  of  the  HSW1). 


At  the  beginning  of  this  project  a plan  was  made  to  carry  out 
the  design  study  through  four  major  steps: 

(1)  modeling  of  the  FTSC, 

(2)  identification  of  feasible  recovery  procedures, 

(3)  specification  of  a recovery  program  in  PASCAL,  and 

(4)  study  the  aspect  of  coding  a recovery  program  in  the  FTSC 
assembly  language. 

The  rationale  for  this  plan  is  given  below. 

First,  it  was  felt  that  systematic  search  for  various  effective 
recovery  procedures  could  be  greatly  assisted  by  working  with  a 
machine  model  which  hides  many  recovery-irrelevant  features  of  the 
sophisticated  FTSC.  Modeling  of  the  FTSC  was  also  motivated  by  the 
hope  that  a properly  chosen  model  would  facilitate  the  validation  of 
the  capability  and  efficiency  of  a resulting  recovery  program. 

Secondly,  after  determining  a recovery  procedure  based  on  a FTSC 
model,  one  could  directly  convert  the  procedure  into  a final  recovery 
program  (i.e.,  an  assembly/machine  language  program).  However,  it 
seemed  clear  that  validation  of  such  a recovery  program  would  be 
Inefficient,  especially  considering  the  numerous  unusual  situations 
that  a recovery  program  must  circumvent  and  the  large  number  of  test 
cases  that  may  be  required.  Modification  or  debugging  of  such  a > 
program  would  also  be  difficult.  Therefore,  the  chance  of  success  in 
obtaining  a robust  recovery  program  was  expected  to  be  greatly 
enhanced  by  obtaining  a high  level  language  version  of  a recovery 
program  first,  checking  it  out  by  a compiler,  and  then  developing  a 
final  recovery  program  by  using  the  high  level  language  version  as  a 
specification.  The  language  chosen  is  PASCAL.  The  natural  control 
primitives  (e.g.,  if-then-else , case,  while-do,  etc)  would  relieve 
the  designer  of  the  burden  of  implementing  equivalent  control 
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sequences  in  inconvenient  assembly  language  primitives.  In  fact,  it 
was  necessary  to  augment  PASCAL  with  a recovery  block  to  experiment 
fault-tolerant  programming.  A translator  that  translates  a program 
written  in  PASCAL  augmented  with  the  recovery  block  into  an 

j 

equivalent  program  in  ordinary  PASCAL,  has  been  developed.  It  is 
documented  in  [K2]. 


ft 
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4 . Design  strategies 


Several  strategies  that  have  been  followed  throughout  the  design 
and  found  to  be  useful  in  obtaining  an  easily  understandable  recovery 
program,  are  now  discussed. 

4. 1 Fixed  ordering  of  units  for  recovery 

When  fault  monitors  are  distributed  among  various  modules,  it  is 
highly  tempting  to  check  and  recover  modules  in  varying  orders 
depending  upon  how  some  modules  indict  the  others.  However,  this  is 
a dangerous  strategy,  considering  the  possible  occurrence  of  multiple 
faults  (i.e.,  simultaneous  occurrences  of  faults  in  multiple  modules 
or  failure  of  a module  before  another  already  faulty  module  is 
located  and  amputated)  as  well  as  the  indictment  of  operational 
modules  made  by  the  faulty  modules.  In  other  words,  the  behavior  of 
a recovery  program  based  on  such  a strategy  in  the  presence  of 
multiple  faults  is  difficult  to  predict. 

For  example,  assume  that  from  the  received  fault  reports  the  CCU 
has  identifed  a certain  fault  category  that  may  be  caused  by  either  a 
malfunctioning  CPU  or  a malfunctioning  (A-/D-)  bus.  If  the  CPU  is 
first  tested  using  the  untested  bus  and  the  actual  faulty  unit  is  the 
bus,  disagreement  between  the  A-CPU  and  the  M-CPU  may  result  and  lead 
the  recovery  program  to  implicate  the  CPU  of  being  faulty.  On  the 
other  hand,  if  the  bus  is  first  tested  using  the  untested  CPU  while 
the  CPU  is  malfunctioning,  the  CPU  could  mistakenly  cause  a good  bus 
to  be  diagnosed  as  the  faulty  one.  Worse  yet,  bus  reconfiguration 
and  reentry  of  the  malfunctioning  CPU  into  the  recovery  program  could 
lead  to  an  endless  loop.  In  this  sense  an  endless  loop  means  an 
infinite  repetition  of  entering  the  recovery  program  caused  by  an 
unidentified  faulty  module  while  there  remain  a sufficient  set  of 
operational  modules  to  form  an  operational  configuration. 


To  alleviate  such  problems,  it  is  useful  to  observe  the  rule  of 
recovering  units  in  the  same  fixed  order  and  using  only  the  already 
validated  (and  recovered)  units  in  recovering  other  units.  Under  the 
rule  the  total  recovery  process  becomes  a strictly  linear  sequence  of 
unit  recoveries.  To  illustrate  some  implementation  aspects  of  the 
rules,  consider  a system  of  three  units  ordered  as  shown  in  Figure  2. 
Unit  U 1 occupies  the  first  position  and  is  assumed  to  be  hardcore. 
Assume  that  U1  is  capable  of  performing  the  function  of  the  CCU  in 
the  FTSC,  i.e.,  receiving  fault  reports  and  invocation  of  the 
recovery  program,  and  also  that  the  execution  of  a recovery  program 
can  be  started  by  using  U1  only.  The  initial  segment  of  the  recovery 
program  first  tests  and  recovers  unit  U2  and  during  this  process  it 
must  not  use  unit  U3  in  any  way.  Furthermore,  if  unit  U3  contains  a 
monitor  which  can  indict  unit  U2  and  can  cause  the  recovery  program 
to  be  reentered,  then  either  the  monitor  must  be  disabled  or  U1  must 
be  armed  to  ignore  a fault  report  from  the  monitor  (during  the 
testing  of  U2)  since  U3  cannot  be  trusted  yet. 

After  recovering  U2,  the  recovery  program  proceeds  to  test  and 
recover  U3  and  during  this  process  the  recovery  program  may  rely  upon 
the  monitoring  capabilities  of  U1  and  U2.  At  this  time  it  is 
possible  that  U2  is  faulty  because  of  two  reasons  although  both  cases 
have  very  low  probability  of  occurrence.  First,  even  though  U2  was 
recovered  earlier,  it  could  have  become  faulty  by  the  time  when  U3  is 
under  test.  Second,  the  recovery  program  could  have  misjudged  a 
fault.,  12  module  as  an  operational  module  and  (thus  misjudged  that  U2 
waa  recovered).  Therefore,  the  recovery  program  must  be  designed 
such  that  when  all  possible  configurations  of  U3  have  been  tried  and 
have  failed  in  validation,  the  configuration  of  U2  is  changed  and 
validation  of  U3  is  reattempted.  It  is  of  course  possible  that  the 
monitors  in  U1  and/or  U2  detect  the  faulty  condition  of  U2  and  report 
to  U1  before  all  possible  configurations  of  U3  are  tried,  in  which 
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case  U1  will  reconfigure  U2  and  reinvoke  the  recovery  program. 

4.2  No  trust  of  a module  by  default 

Since  the  FTSC  hardware  (especially  the  CCU)  keeps  a 
considerable  amount  of  information  on  the  fault  that  has  caused  a 
recovery  program  to  be  entered,  it  is  highly  tempting  to  assume, 
during  the  design  of  a recovery  program,  that  units  not  implicated  by 
the  hardware  status  words  (HSWs)  are  operational.  Such  an  assumption 
may  not  be  valid  because  occurrence  of  another  fault  during  recovery 
of  a previous  fault  is  a real  possibility  and  may  destroy  the 
information  in  the  HSW  registers  about  the  first  fault.  Therefore, 
it  was  made  a rule  to  assume  on  entry  of  a recovery  program  that 
every  module  could  be  faulty  and  to  trust  a module  only  after  it 
passes  an  explicit  test.  In  other  words,  recovery  was  regarded  as  a 
process  of  finding  operational  modules  out  of  all  potentially  faulty 
modules  rather  than  a process  of  finding  faulty  modules  from  a 
configuration  of  mostly  working  modules.  This  conservative  approach 
facilitates  the  design  of  a recovery  program  that  avoids  entering  an 
endless  loop. 

4.3  Redundant  design 

Unlike  the  behavior  of  a correct  machine,  the  behavior  of  a 
faulty  machine  is  very  difficult  to  predict.  From  the  beginning  it 
was  expected  to  be  a difficult  task  to  find  a single  recovery 
procedure  which  works  under  all  possible  circumstances.  Therefore, 
it  was  also  made  a rule  to  mobilize  a set  of  alternate  procedures. 
These  alternates  can  be  specified  in  a well-structured  form  by  use  of 
the  recovery  block.  Additional  specific  justifications  for  this 
redundant  design  are  given  in  section  6. 
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Finally  it  was  decided  that  wherever  there  is  a trade-off 
between  simplicity  and  efficiency,  simplicity  would  be  given  a 
priority.  Only  if  a recovery  program  resulted  from  this  strategy 
fails  to  meet  the  performance  requirement,  then  various  ways  of 
optimizing  the  program,  preferrably  without  changing  the  overall 
program  structure,  can  be  sought  for. 


5 . Basic  functions  of  a recovery  program  and  modeling  of  the  FTSC 


As  mentioned  before,  a recovery  program  in  the  FTSC  is 
responsible  for  establishing  an  operational  hardware  configuration 
and  recovering  some  of  the  lost  information  in  the  memory.  In  other 
words,  a recovery  program  identifies  a set  of  operational  modules 
sufficient  for  normal  processing  and  then  restores  the  system  to  an 
executable  state  (i.e.,  restores  important  memory  contents  and 
conditions  peripheral  units  to  the  states  ready  for  normal  processing 
by  appropriately  setting  control  registers  contained  in  them).  (On 
completion  of  the  execution  of  a recovery  program,  the  executive 
(i.e.,  supervisor)  program  will  enter  and  schedule  application  tasks 
to  restart  from  their  rollback  points.)  A useful  FTSC  model  must 
therefore  illuminate  the  procedure  of  expanding  the  set  of  trusted 
modules  until  an  operational  configuration  is  established.  A natural 
modeling  criteria  is  the  operational  precedence  among  functional 
units  (each  consisting  of  multiple  modules).  If  unit  A has  higher 
operational  precedence  than  unit  B,  then  unit  B cannot  operate 
reliably  unless  unit  A is  operational.  Figure  3a  depicts  a FTSC 
model  displaying  the  operational  precedence  among  units.  The 
rationale  for  the  ordering  in  Figure  3a  is  the  following. 

(1)  Since  the  PU  supplies  the  power  to  all  other  units,  it  must  be 
working  reliably  before  any  other  unit  can  be  used.  Naturally  it  has 
the  highest  operational  precedence. 

(2)  The  unit  having  the  next  highest  operational  precedence  is 
somewhat  arbitrarily  chosen  to  be  the  CU.  It  depends  only  on  the  PU 
for  proper  functioning. 

(3)  The  operation  of  all  other  units  (excluding  the  PU  and  the  CU) 
depends  upon  the  correct  clock  signals  supplied  by  the  TU.  Thus  the 
TU  has  the  third  highest  operational  precedence. 

(4)  The  HT  maintains  the  record  of  elapsed  time  during  the  periods  of 
PU  failure  and  high  radiation  event.  The  proper  operation  of  the  HT 
is  dependent  only  upon  the  PU,  CU,  and  TU.  The  CCU  is  also  dependent 
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only  on  the  PU,  CU,  and  TU.  Therefore,  both  the  HT  and  the  CCU 
t _ immediately  follow  the  TU  in  the  order  of  operational  precedence. 

The  HT  provides  information  important  to  some  (real-time)  application 
tasks,  but  no  functional  unit  in  the  FTSC  is  really  dependent  on  it. 
j In  contrast,  if  the  CCU  is  not  operational,  no  other  remaining  units 

such  as  the  CPU,  buses,  MMU,  etc  can  be  relied  upon. 

(5)  If  all  the  units  placed  below  CPU  in  Figure  3a  as  well  as  the  CPU 
function  properly,  then  the  CPU  can  execute  the  part  of  the  recovery 
program  that  does  not  involve  the  use  of  the  units  placed  above  the 
CPU.  For  example,  the  CPU  can  interact  with  the  CCU  and  this  does 
not  involve  buses  except  (a  part  of)  the  S-bus.  On  the  other  hand, 
the  A-bus,  D-bus,  or  C-bus  are  useless  if  the  CPU  is  not  available 
because  the  CPU  is  normally  in  control  of  these  buses.  Thus  the  CPU 
is  regarded  as  having  higher  operational  precedence  than  those  buses. 

(6)  The  A-bus  and  D-bus  are  usable  by  various  functional  units  only 
if  the  C-bus  is  operational,  but  not  vice  versa  - 

(7)  Similarly  the  MMU  and  peripheral  units  (i.e.,  DMAs  and  SIU)  are 
regarded  as  having  lower  operational  precedences  than  the  A~bus  and 
D-bus  because  they  are  not  usable  if  the  buses  are  not  working. 

Figure  3b  depicts  the  same  model  in  Figure  3a  in  the  form  of  a 
precedence  graph  with  one  modification.  The  modification  is  In  the 
separation  of  MMU  modules  into  two  sets:  one  consisting  of  two 

modules  called  system  memory  modules  and  the  otheo  consisting  of 
remaining  modules  called  application  memory  modules.  The  two  system 
memory  modules  contain,  among  other  important  information,  an 
executive  program  and  duplicate  copies  of  the  system  map  that  shows 
the  status  and  functional  assignment  of  both  peripheral  modules  and 
memory  modules.  For  example,  a par-t  of  the  system  map  is  a table 
showing  for  each  memory  module  the  soft  name  assigned,  the  current 
bit  line  configuration  (i.e.,  the  three  bit  lines  that  are  not  In 
use),  the  status  (i.e.,  active,  available  spare,  or  unusable),  etc. 
Thus  the  system  map  represents  the  most  recently  established 
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configurations  of  peripheral  units  and  the  MMU.  In  addition,  what  is 
more  important  from  the  recovery  point  of  view  is  the  useful  content 
of  an  MMU  module  rather  than  the  module  itself.  Some  memory  contents 
cannot  be  recovered  (to  be  more  exact,  are  not  identifiable)  if  the 
system  map  is  lost,  although  the  operational  capability  of  memory 
modules  can  be  validated  without  using  the  system  map.  It  thus  seems 
useful  to  regard  the  system  memory  as  one  having  higher  operational 
precedence  than  the  application  memory.  Similarly,  the  execution 
states  of  peripheral  units  cannot  be  completely  restored  without 
using  the  system  map,  although  the  operational  capability  of  their 
modules  can  be  validated  without  using  the  map. 

The  units  marked  * in  Figure  3b  are  the  TMR-conf igured  ones  and 
thus  their  internal  faults  are  masked  off  (privided  that  two  out  of 
three  modules  are  operational  at  any  one  time).  In  fact,  all  the 
units  that  have  higher  operational  precedence  than  the  CPU  are 
automatically  recovering  ones  and  thus  compose  the  hardcore  that  does 
not  burden  the  recovery  program. 
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6.  Recovery  procedure 

In  principle,  the  overall  recovery  process  can  be  designed  in  a 
straightforward  manner  on  the  basis  of  the  FTSC  model  presented  in 
the  preceding  section.  The  process  should  essentially  be  a 
step-by-step  expansion  of  the  set  of  trusted  modules  in  a decreasing 
order  of  the  operational  precedence.  The  order  in  which  the  modules 
having  the  same  operational  precedence  are  tested  and  recovered  is 
immaterial  as  long  as  the  same  fixed  order  is  used  consistently. 

In  the  FTSC,  TMR-configured  and  automatically  recovering  units 
form  the  hardcore.  No  capability  is  provided  within  the  FTSC  for 
direct  repair  or  reconfiguration  of  the  hardcore.  (The  FTSC  was 
designed,  however,  to  allow  the  ground  station  to  Intervene  and 
control  various  functional  units  after  failure  of  more  than  one  CCU 
module.  This  ground-override  mode  is  outside  the  scope  of  this 
paper.)  Thus  the  correct  operation  of  these  functional  units  must  be 
trusted  by  a recovery  program  without  explicit  checks. 

When  a recovery  program  is  entered,  a certain  amount  of 
information  on  system  status  including  the  categorized  fault  report 
is  available  from  the  HSWs . By  utilizing  this  information  a recovery 
program  can  establish  a working  configuration  in  an  efficient  manner. 
Basically  faults  of  multiple  modules  causing  an  Invocation  of  a 
recovery  program  are  less  probable  than  faults  in  a single  module. 
In  other  words,  if  the  categorized  fault  report  implicates  a certain 
module  of  being  faulty,  then  the  probability  of  other  modules  being 
faulty  at  the  same  time  is  small.  Thus,  the  recovery  program  can 
check  the  implicated  module  more  thoroughly  than  other  modules.  This 
strategy  of  using  "weak"  and  "strong  (thorough)"  tests  is  of  course 
somewhat  against  the  aforementioned  rule  of  not  trusting  any  module 
by  default.  However,  it  is  a way  of  reducing  the  (average)  execution 
time  of  the  recovery  program,  thereby  reducing  the  probability  of  the 
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program  failing  in  meeting  the  execution  time  requirement.  Later  an 
analysis  may  reveal  that  the  worst-case  execution  time  of  a final 
recovery  program  is  far  less  than  the  tolerable  limit.  In  such  case, 
some  weak  (module)  tests  can  be  deleted  to  leave  only  strong  tests  in 
the  recovery  program,  thereby  increasing  the  robustness  of  the 
program  even  further.  A penalty  Incurred  by  using  aj i weak  test  is 
the  increased  probability  of  a faulty  module  being  undetected  (i.e., 
validated).  Therefore,  in  order  to  make  use  of  weak  tests  without 
much  sacrificing  the  capability  of  correct  recovery,  an  acceptance 
test  needs  to  be  provided  at  the  end  of  a recovery  program  to  ensure 
that  the  entire  computer  system  has  been  correctly  recovered.  An 
alternate  procedure  which  uses  only  strong  tests  must  also  be 
provided  to  recover  the  system  if  the  result  of  the  primary  procedure 
is  rejected  by  the  acceptance  test.  Thus  the  use  of  weak  and  strong 
tests  is  to  trade  the  increase  of  the  worst-case  recovery  time  for 
reduction  of  the  average  recovery  time. 

The  transient  faults  are  expected  to  be  the  predominant 
fault-type.  The  occurrence  of  a transient  fault  can  be  determined  if 
the  module  that  has  been  Indicted  passes  a (strong)  test. 
Nevertheless,  the  source  of  the  transient  fault  is  not  always  easy  to 
locate.  For  instance,  if  the  A-bus  has  been  indicted  but  both  the 
A-bus  and  its  most  recent  user  DMA1  (that  loaded  an  address  on  the 
bus  at  the  time  of  fault  reporting)  pass  (strong)  tests,  then  one  may 
conclude  that  a transient  fault  has  occurred.  Both  the  A-bus  and 
DMA  1 will  be  suspected  as  the  possible  sources  of  the  transient  fault 
but  the  exact  source  cannot  be  identified.  It  is  useful  to  maintain 
a transient  fault  count  and  to  set  a tolerable  limit  to  the  count  for 
each  module.  When  this  limit  is  reached,  the  associated  module  can 
be  treated  as  an  unusable  module  and  thus  replaced  by  a standby 
module.  The  procedure  of  updating  transient  fault  counts  is  not 
detailed  in  this  paper. 
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The  recovery  consists  of  the  following  sequence  of  actions. 

(1)  validation  of  the  CPU's  capability  of  reading  the  hardware  status 
words, 

(2)  validation  and  necessary  reconfiguration  of  the  CPU, 

(3)  validation  and  necessary  reconfiguration  of  the  A-bus  and  the 
D-bus, 

(4)  recovery  of  the  system  memory, 

(5)  reoovery  of  peripheral  units, 

(6)  recovery  of  the  application  memory, 

(7)  acceptance  test  of  the  new  system  configuration  (i.e.,  result  of 
the  recovery)  and  normal  processing  restart. 

The  rest  of  this  section  briefly  explains  the  above  actions. 

The  first  action  taken  by  a recovery  program  is  to  check  if  the 
present  CPU  can  correctly  read  the  HSWs.  Failure  of  this  validation 
will  result  in  reconfiguring  the  CPU  (i.e.,  selecting  a new  pair  of 
CPU  modules  as  the  A-  and  M-  CPUs)  and  reinvoking  a recovery  program. 
If  the  validation  is  sucoessful,  then  the  recovery  program  will 
proceed  to  check  the  CPU  (to  be  exact,  the  part  of  the  CPU  not  used 
in  reading  the  HSWs)  because  the  CPU  has  the  highest  precedence  among 
the  units  that  need  to  be  checked. 

If  the  HSWs  indicate  the  occurrence  of  a CPU  reconfiguration, 
then  the  (current)  CPU  is  thoroughly  tested.  Otherwise,  a weak  test 

procedure  is  used.  In  any  case,  if  the  CPU  fails  in  validation,  it 

must  be  reconfigured.  (Recall  the  CCU  command  provided  for  this 
programmed  reconfiguration.)  Both  weak  and  strong  test  prooedures  for 
the  CPU  are  detailed  in  Appendix  C.  By  the  rule  of  fixed-order  unit 
recovery,  a CPU  test  procedure  must  not  use  any  unit  (Including  the 
A-  /D-  bus)  having  a lower  operational  precedence  than  the  CPU.  This 
means  that  a faulty  condition  of  the  CPU  must  be  detected  by  the  CCU 

(that  has  the  higher  operational  precedence  than  the  CPU). 


Therefore,  a CPU  test  procedure  is  generally  designed  to  compute  a 
function  by  using  certain  parts  of  a CPU  module  and  then  send  a CCU 
command  (through  a part  of  the  TMR-configured  S-bus)  if  the 
computation  result  is  in  a certain  expected  range.  The  function  must 
be  chosen  such  that  if  the  parts  of  a CPU  module  under  test  are 
faulty,  the  probability  of  the  result  being  out  of  the  expected  range 
and  thus  no  CCU  command  being  sent  out  is  very  high.  When  the  CCU 
receives  a CCU  command  from  only  one  of  the  two  powered  CPU  modules, 
the  CCU  reconfigures  the  CPU.  Since  the  M-CPU  monitors  the  C-bus  and 
the  C-bus  is  TMR-conf igured , a thought  was  given  at  first  to  the 
possibility  of  using  the  C-bus  in  validating  the  CPU  although  che 
C-bus  is  placed  above  the  CPU  in  Figure  3b.  This  could  not  be 
implemented  because  the  FTSC  instruction  set  did  not  include  an 
instruction  which  changes  the  C-bus  only  (without  affecting  the  A-/D- 
bus) . 


Use  of  a weak  test  procedure  can  be  justified  only  if  a strong 
test  procedure  requires  a large  execution  time  and  the  weak  test 
procedure  can  detect  a faulty  module  with  much  reduced  execution  time 
and  yet  with  little  reduoed  effectiveness  of  diagnosis.  This  was  not 
the  case  in  validating  the  A-bus  and  the  D-bus.  Therefore,  only  a 
strong  test  procedure  was  provided.  In  addition,  the  same  test 
procedure  can  be  applied  to  both  the  A-bus  and  the  D-bus. 

By  the  rule  of  fixed-order  unit  recovery,  the  validation  of  the 
A-/D-  bus  must  be  performed  free  of  the  interference  by  the  units 
having  lower  operational  precedences  than  the  A-/D-  bus.  The  FTSC 
was  designed  to  ease  the  implementation  of  this  procedure.  If  flag  1 
is  not  set  while  the  system  is  in  the  reconfiguration  state,  the  MMU, 
SIU,  and  DMA  modules  do  not  attend  to  the  buses.  Thus  detection  of  a 
faulty  bus  relies  upon  the  bus  code  monitors  contained  in  the  CPU. 
(It  was  assumed  that  the  M-CPU  will  report  to  the  CCU  the 
disagreement  with  the  A-CPU  only  if  the  information  on  the  bus  is  a 
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valid  coda.)  The  test  procedure  Involves  repeatedly  placing  a 'O'  and 
a M'  on  each  bit  position  of  a bus. 

Having  established  a jrf  working  configuration  of  the  CPU,  the  A- 

bus,  and  the  D-bus,  the  next  step  is  to  recover  the  system  memory 

modules.  Flag  1 is  first  set  so  that  the  MMU,  DMA,  and  SIU  modules 

may  respond.  Now  whenever  a word  is  loaded  onto  a bus,  a peripheral 

module  containing  a 'crazy'  bus  code  monitor  can  report  to  the  CCU 
the  detection  of  an  invalid  code  on  the  bus  even  though  the  bus  is 
correct  and  the  word  loaded  is  a valid  code.  It  is  also  possible 
that  a malfunctioning  (powered)  peripheral  module  may  respond  to  an 
address  which  is  not  the  one  assigned  to  itself.  Since  the  system 
memory  recovery  must  be  performed  free  of  interference  by  the  units 
having  lower  operational  precedences  than  the  system  memory,  all  the 
peripheral  units  are  powered  off  before  search  for  the  system  memory 
modules  begins.  During  the  execution  of  a power-off  command  for  a 
peripheral  unit,  another  peripheral  unit  may  interfere  by  generating 
a Cat  IV  fault  since  the  command  involves  the  use  of  the  A-bus. 
Therefore,  flag  3 must  be  set  in  advance  to  mask  such  fault  reports. 
Note  also  that  a module  may  "resist"  to  obey  che  power-off  command; 
it  can  then  be  powered  off  only  when  the  system  enters  an  alexic 
state . 


A system  memory  module  is  assigned  a soft  name  0 or  1 . An 
operational  system  memory  module  contains  a special  bit  pattern, 
called  a map  flag,  in  its  last  looation  (address:  4095).  Therefore, 
even  if  the  contents  of  soft  name  registers  in  system  memory  modules 
are  lost  due  to  PU  failure  or  other  faults,  it  is  possible  to 
identify  a system  memory  module  by  checking  the  last  location  in 
non-volatile  memory.  In  the  FTSC,  a memory  location  can  be  read  only 
by  a soft  address.  It  may  seem  reasonable  that  if  it  is  suspected 
that  most  memory  modules  are  powered  on  (after  setting  flag  1),  then 
a memory  read  can  be  commanded  with  soft  name  0 (or  1)  and  location 
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address  4095  to  see  if  the  value  read  is  a valid  map  flag.  However, 
a malfunctioning  memory  module  could  have  0 as  its  soft  name  and  thus 
more  than  one  memory  module  may  respond  to  soft  name  0 (or  1). 
Therefore,  it  was  decided  to  turn  all  the  memory  modules  off  and  then 
power  at  most  one  of  them  on  at  any  time  during  the  searah  for  system 
memory  modules.  (In  the  case  where  volatile  memory  modules  are  used 
together  with  backup  batteries,  the  above  strategy  may  be  overly 
conservative  and  a different  strategy  may  be  desired.) 

The  search  for  system  memory  modules  will  result  in  one  of  three 
different  situations:  none  found,  only  one  found,  and  both  system 
memory  modules  found.  In  the  first  (infrequent)  case  where  no  system 
memory  modules  have  been  found,  a "cold  restart"  procedure  is  entered 
to  establish  the  system  memory  by  using  the  information  stored  in  the 
backup  memory.  The  cold  restart  Involves  finding  two  operational 
memory  modules  and  one  operational  DMA  module  and  then  establishing 
the  system  memory  (i.e.,  loading  system  software  Including  the 
executive  program  from  a backup  memory  into  the  two  memory  modules 
using  the  operational  DMA  module  and  initializing  system  maps  In  the 
modules).  In  the  second  case  where  only  one  system  memory  module  has 
been  found,  the  module  is  tested.  If  it  passes  the  test,  then 
another  operational  memory  module  (preferably  a module  designated  as 
a spare  in  the  system  map  contained  in  the  Just  validated  system 
memory  module)  is  found  and  made  the  other  system  memory  module. 
That  is,  the  system  map  is  copied  into  the  newly  assigned  system 
memory  module  and  some  system  software  is  loaded  onto  the  module  from 
the  backup  memory.  If  the  first  found  system  module  falls  the  test, 
then  the  cold  restart  procedure  is  entered.  In  the  third  case  when 
both  system  memory  modules  have  been  found,  the  two  modules  are 
tested  and  if  any  of  them  is  found  to  be  faulty,  the  procedures  used 
in  the  previous  two  cases  can  be  used  again  to  recover  the  entire 
system  memory. 
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With  the  properly  recovered  system  map,  an  operational 
configuration  of  peripheral  units  can  be  established  efficiently. 
The  modules  indicated  to  be  faulty  in  the  system  map  need  not  be 
(powered  on  and)  aocessed  at  all.  On  the  other  hand,  each  module 
indicated  to  be  operational  in  the  system  map  is  powered  on  and 
tosted  by  a strong  test  procedure  if  the  module  is  implicated  by  the 
HSWs,  and  by  a weak  test  procedure,  otherwise.  A peripheral  module 
is  implicated  when  the  present  execution  of  the  recovery  program  was 
caused  by  one  of  the  following  events:  (1)  the  module  had  reported 
the  detection  of  an  invalid  code  on  the  A-/D-  bus  without  being 
corroborated  by  other  units,  i.e.,  a Cat  IV  fault  had  occurred,  (2) 
the  address  that  the  module  had  loaded  on  the  bus  for  reading  from  or 
writing  into  a memory  location  was  an  invalid  code,  i.e.,  Cat  Ilia 
fault  had  occurred  (but  since  then  the  A-bus  has  been  validated),  and 
(3)  the  data  that  the  module  had  loaded  on  the  D-bus  for  writing  into 
a memory  location  was  an  invalid  code. 

The  last  unit  to  be  recovered  is  the  application  memory. 
Recovery  of  the  application  memory  consists  of  two  steps:  one  to 
identify  all  the  operational  memory  modules  and  the  other  to  recover 
the  application  information  (i.e.,  the  content  of  the  application 
memory  that  had  existed  prior  to  the  fault  that  caused  the  entry  of 
the  recovery  program).  Similar  to  the  establishment  of  an 
operational  configuration  of  peripheral  units,  only  the  (application 
memory)  modules  Indicated  to  be  operational  in  the  system  map  are 
accessed.  Again  a module  is  tested  by  a strong  test  procedure  if  it 
is  implicated  by  the  HSWs,  and  by  a weak  test  procedure,  otherwise. 
A memory  module  is  implicated  when  all  of  the  following  three 
conditions  are  met:  (1)  the  HSWs  indicate  the  occurrence  of  a Cat 
Hid  fault  (i.e.,  detection  of  an  invalid  code  on  the  D-bus  by  more 
than  one  unit)  as  the  cause  of  the  present  execution  of  the  recovery 
program;  (2)  the  HSWs  indicate  that  a memory  read  operation  was  in 
execution  when  the  fault  occurred  and  the  address  used  corresponds  to 
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the  module;  and  (3)  the  D-bus  has  been  validated.  If  the  CPU  was  in 
control  of  both  the  A-bus  and  the  D-bus  when  the  fault  occurred,  then 
the  address  used  Is  kept  In  a field  of  a hardware  status  word 


register.  On  the  other  hand,  if  a peripheral  module  was  in  control 
of  the  buses,  then  the  address  used  is  kept  in  a field  of  a status 
register  of  the  module.  Recall  that  at  the  beginning  of  the  recovery 
of  the  system  memory  peripheral  units  are  powered  off  and  the 
contents  of  their  status  registers  are  lost.  Therefore,  before 
taking  power  off  a peripheral  module  that  keeps  the  most  recently 
used  address  in  its  status  register,  the  recovery  program  must  copy 
the  content  of  the  status  register  into  a register  within  the  CPU. 
The  procedure  of  recovering  the  application  information  (after 
identifying  all  the  operational  memory  modules)  is  essentially  that 
described  in  [D1,L1]. 


Once  all  the  units  up  to  the  application  memory  have  been 
recovered,  an  acceptance  test  designed  to  check  the  acceptability  of 
the  recovery  program  execution  (i.e.,  to  check  if  the  system  has  been 
properly  recovered)  is  executed.  This  is  motivated  by  the  following 
considerations.  First,  a certain  unit  that  has  already  been 
recovered  may  become  faulty  during  recovery  of  other  units  and  remain 
undetected  until  the  acceptance  test  is  executed.  This  is  a rather 
minor  motivation  because  (1)  the  CPU  and  the  buses  are  monitored  at 
high  frequency  and  thus  only  the  peripheral  units  and  the  MMU  can 
have  non-  negligible  latent  faults,  and  (2)  even  if  there  is  a faulty 
unit  on  resumption  of  normal  processing,  the  unit  can  be  detected 
later  and  recovered  by  execution  of  the  recovery  program. 
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A more  potentially  serious  factor  that  justifies  the  use  of  the 
acceptance  test  is  the  possibility  of  incorrect  recovery  of  a certain 
faulty  unit  by  an  (imperfect)  recovery  procedure.  If  the  unit  is 
detected  later  during  normal  processing,  the  recovery  program  may 
again  incorrectly  recover  the  unit,  thus  leading  to  a disastrous 
loop.  This  rather  pessimistic  but  pragmatic  attitude  is  based  on 
recognizing  the  difficulty  of  complete  understanding  (or  perfect 
analysis)  of  the  behavior  of  a faulty  machine.  It  is  realistic  to 
assume  that,  given  any  single  recovery  procedure,  situations  could 
arise  where  the  procedure  is  not  effective.  It  is  thus  a pratical 
necessity  to  make  provisions  in  the  recovery  program  for  attempting 
to  circumvent  the  situation  after  a recovery  procedure  has  failed 
(i.e.,  for  tolerating  or  covering  up  some  local  design 
faults/inadequacies  during  execution).  The  aforementioned  loop  can 
be  broken  only  if  a different  recovery  procedure  is  tried.  The 
acceptance  teat  is  obviously  a means  of  recognizing  the  need  for 
execution  of  an  alternate  recovery  procedure. 

It  is  desirable  that  alternate  recovery  procedures  be  logically 
simpler  and  also  take  more  global  (or  drastic)  recovery  actions  than 
the  primary  recovery  procedure.  An  alternate  that  we  adopted,  takes 
the  following  actions:  (1)  it  recovers  the  CPU  and  the  buses  by  use 
of  strong  tests  only,  (2)  it  uses  (only)  the  cold  restart  procedure 
to  recover  the  system  memory,  and  (3)  it  recovers  the  peripheral 
units  and  the  application  memory  again  by  use  of  strong  tests  only. 
This  alternate  is  substantially  simpler  in  logic  than  the  primary 
although  it  may  require  a larger  execution  time. 


37 


The  acceptance  teat  playa  an  Important  role  In  lnoreaalng  the 
robuatneaa  of  the  total  recovery  program.  Two  Important  requirementa 
of  an  effective  acceptance  teat  are  the  almpllclty  and  the  logical 
Independence  from  the  primary  or  alternate  recovery  procedures.  That 
la,  the  logic  of  an  acceptance  test  must  be  simple  so  that  the 
probability  of  having  an  Incorrectly  designed  acceptance  test  may  be 
minimized.  In  addition,  It  must  be  Independent  of  the  logic  of  the 
primary  or  alternate  recovery  procedures  so  that  the  probability  of 
having  similar  errors  in  both  the  recovery  procedures  and  the 
acceptance  test  may  also  be  minimized.  The  acceptance  test  that  we 
adopted,  takes  advantage  of  the  following  property:  if  the  new 
system  configuration  is  operational,  then  computation  of  a function 
that  involves  the  use  of  any  parts  of  the  configuration  In  an 
arbitrary  sequence  must  produce  a correct  result.  It  also  seemed 
useful  to  take  advantage  of  the  following  property:  the  difference 
between  the  old  system  configuration  (i.e.,  the  configuration  prior 
to  the  execution  of  a recovery  procedure)  and  the  new  system 
configuration  (i.e.,  the  configuration  after  the  execution)  must  not 
be  contradictory  to  the  HSWs  (specifically  the  information  on  the 
most  recently  reported  fault).  For  instance,  if  the  difference  is 
only  in  the  SIU  configuration,  then  the  acceptance  test  can  check  if 
the  HSWs  have  implicated  the  (previous)  SIU  configuration  or  any  unit 
that  can  be  affected  by  a malfunctioning  SIU.  However,  this  approach 
was  not  adopted  because  of  the  difficulty  of  the  complexity  of  the 
logic  and  the  difficulty  in  saving  information  on  an  old  system 
configuration. 

If  an  incorrectly  recovered  unit  is  detected  before  the 
initiation  of  the  acoeptanoe  test  and  followed  by  reinvocation  of  the 
recovery  program,  then  a disastrous  looping  can  still  occur  (beoause 
an  alternate  recovery  program  will  not  be  executed).  Since  the  CPU 
and  the  buses  are  automatically  reconfigured  on  detection  of  their 
faults,  an  Infinite  loop  due  to  incorrect  recovery  of  one  or  both  of 
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the  two  unite  ie  unlikely  to  occur  (provided  that  the  probability  of 
the  recovery  program  reconfiguring  an  operational  unit  ie 
negligible).  Therefore,  the  problem  ie  reduced  to  maximizing  the 
probability  of  detecting  a loop  due  to  incorrect  recovery  of  the 
syetem  memory,  peripheral  unite,  and/or  application  memory.  Once  the 
eyatem  memory  ie  recovered,  recovery  indicatora  or  hiatorlea  of 
multiple  conaecutive  executiona  of  the  recovery  program  can  then  be 
recorded  aa  long  as  there  is  storage  apace  within  the  system  memory. 
Thus  if  the  recovery  program  is  reentered  later  but  before  resumption 
of  normal  processing,  then  the  recovery  program  can  learn  by 
examining  the  indicators  that  the  present  execution  is  not  the  first 
execution  since  the  interruption  of  most  recent  normal  processing. 
(In  a sense,  flag  1 serves  the  function  of  a recovery  indicator  to  a 
limited  extent.)  After  some  iterations  the  recovery  program  can 
revert  to  an  alternate  recovery  procedure. 
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7. 


Specification  of  a recovery  program  In  PASCAL 


The  procedure  discussed  in  the  preceding  section  was  specified 
in  PASCAL.  Appendix  B contains  a complete  listing  of  the  PASCAL 
specification.  The  specification  is  in  sufficient  detail  so  that  a 
final  machine  program  can  be  obtained  in  a straightforward  manner 
from  it.  Some  low-level  procedures  were  specified  in  plain  words 
(enclosed  by  '<'  and  '>')  because  their  PASCAL  specification  was  not 
expected  to  be  more  readable  while  their  functions  are  simple. 

There  are  two  types  of  variables  declared  in  the  PASCAL 
specification.  One  set  of  variables  called  system  variables 
represent  storage  components  in  the  FTSC,  i.e.,  registers  and  memory 
words.  The  other  set  of  variables  are  program  variables  that  exist 
only  during  execution  of  a recovery  program.  Each  module  is 
abstracted  into  the  set  of  registers  and  functional  capabilities 
(including  error  detection)  that  the  module  possesses.  The 
abstraction  of  eaoh  type  of  module  is  treated  as  a data  type  in  the 
specification.  Due  to  the  restriction  in  PASCAL,  descriptions  of 
functional  capabilities  of  each  module  were  Introduced  as  comments. 

The  procedures  in  the  PASCAL  specification  are  organized  as 
follows.  The  main  procedure  carries  out  the  sequence  of  functional 
unit  recoveries  as  discussed  in  the  preceding  section.  The  main 
procedure  calls  other  procedures  which  are  divided  into  two  classes; 
the  procedures  of  testing  modules  form  one  class  while  the  remaining 
procedures  form  the  other  class.  Comments  were  inserted  in  various 
places  in  order  to  make  the  entire  program  self-explanatory.  The 
objective  of  each  procedure/function  is  explained  either  immediately 
after  the  procedure/function  statement  or  where  it  is  called  (i.e., 
Inside  the  body  of  a calling  procedure). 


40 


8.  Assembly  language  oodlna  of  the  PASCAL  specification 


Aaaembly  language  coding  of  the  PASCAL  specification  can  be  done 
in  a straightforward  manner.  For  example,  let  ua  consider  the 
following  statement  extracted  from  the  beginning  portion  of  the  main 
procedure. 

for  i:=5  to  8 do 

if  hswl . fault_cat[ i] = 1 then  begin  pflag6;  pflag7  end; 

This  statement  is  designed  to  test  the  CPU's  capability  of  reading 


HSU  1 . 

This  can 

be  coded  as 

follows . 

LDR.2 

=4 

(set  the  iteration  counter) 

LOR,  1 

X 'F800 ' 

(load  regl  with  HSW1) 

LRS,  1 

=-3 

(shift  left  by  3 positions) 

[3961: 

LRS,  1 

=-1 

JPZ,  1 

400 

(skip  if  the  left-most  bit  is  0) 

STZ 

X ' F80E ’ 

(program  flag  6) 

STZ 

X'F807 ' 

(program  flag  7) 

[400] : 

JDN , 2 

396 

(repeat  if  4 iterations  are  not  done) 

The  structure  of  the  PASCAL  specification  should  be  preserved  in 
assembly  language  coding  to  reduce  the  cost  of  debugging  and 
maintenance. 

The  recovery  block  in  the  PASCAL  specification  does  not  require 
saving  any  register  or  memory  word  at  the  beginning  or  in  the  middle 
of  execution  of  the  recovery  program.  It  was  designed  in  that  form 
to  preserve  the  simplicity  of  the  overall  recovery  program.  Thus 
coding  the  recovery  block  in  an  assembly  language  should  again  be 
straightforward . 
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9 . Summary 

Design  of  an  effective  recovery  program  for  a fault-tolerant 
computer  such  as  the  FTSC  represents  a special  type  of  challenge  in 
software  engineering.  The  difficulty  in  this  design  is  related  to 
the  unusual  input  to  this  program,  i.e.,  a faulty  machine  whose 
behavior  is  difficult  to  analyze.  In  view  of  the  vital  role  that  the 
recovery  program  plays  in  fault-tolerant  computing,  it  must  be 
designed  with  simple  (i.e.,  easy  to  understand)  and  systematic 
procedures  of  recovering  the  system.  The  rules  of  fixed-order  unit 
recovery  and  conservative  recovery  discussed  in  section  4 meet  these 
criteria.  Recognizing  the  difficulty  of  complete  understanding  of 
the  behavior  of  a faulty  machine,  it  seems  also  realistic  to  provide 
an  alternate  recovery  procedure  that  can  be  used  when  the  primary  is 
not  effective,  and  the  acceptance  test  that  can  Judge  the 
effectiveness  of  a recovery  procedure  at  run-time.  Measures  of 
success  in  this  direction  largely  depends  upon  the  logical  simplicity 
of  the  acceptance  test  and  the  logical  independence  among  two 
recovery  procedures  and  the  acceptance  test  that  are  used. 

In  order  to  obtain  a well-structured  recovery  program  and  also 
take  advantage  of  available  tools  (applicable  to  high  level  language 
programs) , the  approach  of  first  obtaining  the  high  level  language 
specification  of  a recovery  program  instead  of  directly  constructing 
a machine/assembly  language  recovery  program  was  adopted.  PASCAL  was 
ohosen  as  the  specification  language.  The  PASCAL  specification  is 
almost  as  precise  as  the  machine  program  and  yet  almost  as  readable 
as  a natural  language  specification.  It  can  also  be  checked  out  to  a 
certain  extent  by  using  a PASCAL  compiler,  provided  that  various 
actions  of  the  FTSC  are  simulated  by  (PASCAL)  procedures.  Such  a 
checkout  is  thus  limited  by  the  simulation  cost. 


Although  much  care  has  been  taken  In  this  development  to  obtain 
an  easily  understandable  recovery  program  and  the  checkout  of  the 
program  with  a PASCAL  simulator-compiler  might  be  of  help  In 
establishing  confidence  In  the  correctness  of  the  PASCAL 
specification,  It  seems  worthwhile  and  desirable  to  further  enhance 
the  confidence  through  supplementary  means.  The  application  of  a 
program  verification  approach  to  this  recovery  program  seems  well 
Justified,  considering  the  relatively  small  program  size  and  yet  the 
important  role  of  the  recovery  program.  It  does  not  appear  that 
existing  verification  approaches  can  be  directly  applied  to  the 
recovery  program,  though.  It  seems  that  the  existing  approaches  need 
to  be  modified  or  extended,  partly  due  to  the  fact  that  the  faults 
(which  are  Inputs  to  the  recovery  program)  are  non-deterministic 
events.  This  remains  as  a future  research  subject. 
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Appendix  A:  Syntax  and  semantics  of  a recovery  block 


A recovery  block  (RB)  has  the  following  syntactic  structure: 

ensure  T 
by  01 

else-by  02 


else-by  On 
else-error 

where  T denotes  the  acceptance  test.  01  the  primary  object  block,  and 
Ok  (2_<k_<n)  the  alternate  ob.lect  blocks. 

All  the  object  blocks  in  an  RB  specify  computations  aimed  at 
producing  the  same  or  approximately  the  same  result.  A process 
executes  the  acceptance  test  T on  exit  from  an  object  block  to 
confirm  that  the  result  of  the  object  block  execution  is  acceptable. 
If  it  is  acceptable,  the  process  exits  from  the  RB.  If  it  is  not, 
the  process  enters  the  next  alternate  object  block.  Also,  the 
process  enters  the  next  alternate  object  block  if  the  underlying 
processor  system  detects  an  error  (e.g.,  divide-by-zero)  while  the 
process  is  inside  an  object  block. 

Before  an  alternate  object  block  is  entered,  the  process  state 
is  restored  to  the  state  that  existed  Just  before  entry  to  the 
primary  object  block.  That  is,  the  process  rolls  back  to  the 
recovery  point  (RP)  established  on  entry  to  the  RB.  Each  variable 
that  was  assigned  a new  value  by  the  rejected  execution  is  restored 
to  its  original  value.  The  underlying  processor  system  automatically 
performs  this  "assignment  reversal*.  To  enable  this,  the  first 
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assignment  to  a non-  local  variable  v during  execution  of  an  object 

[ 1 

block  is  preceded  by  the  recording  of  the  original  value  of  v, 
denoted  by  PRIOR(v),  in  the  recovery  cache.  Actually  PRIOR(v)  may 
also  be  used  within  the  acceptance  test  of  the  RB.  These  (first) 
assignment  reoords  need  to  be  kept  until  the  RB  is  successfully 
~ exited.  When  an  RB  is  exited,  the  RP  established  on  entry  to  the  RB 

may  be  discarded. 


Appendix  B:  PASCAL  specification  of  an  FTSC  recovery  program 


const  faulty  *0; 

working  »1j 

yes  »1; 

no  s0; 


lastmodid  >59;  (*no  of  modules*) 


dummy  >0; 

catl  =15; 

cat2  =12; 

cat3a  =8; 

cat3b  =9; 

cat4a  =3; 

cat 4b  =1; 

cat4c  =2; 

cat4d  =6; 

catUe  =7; 

mmuid  = 1 ; 

siuld  =2; 

dmalid  =3; 

dma2id  = 4^' 

cpuid  *5; 

abusid  =6; 

dbusid  =7; 

ccuid  =8; 

htid  =9; 

cuid  =10; 

tuid  =11; 

puld  =12; 

mmusize  =24; 


bustestreptition  = 8; 


type  bit  *(0,1); 

register=array[0. .31]  of  bit; 
word  =array[0. . 40]  of  bit; 

reg2  =array[0..1]  of  bit; 

reg3  =array[0..2]  of  bit; 

reg4  =array[0..3]  of  bit; 

( *monitor=procedure* ) 

(• •) 

(•module  types*) 

(• •) 

cpumodule= ( *module*) 

record 

hswl  : record 

flag :array[ 1 • . 3]  of  bit; 

(•actual  bit  position:  0..2*) 
alexic indicator :bit ; 
fault_cat:array[5- .8]  of  bit; 
statechange:bit; 
cputest :bit ; 
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simplexmode : bit ; 

busarbiter:array[ 12. . 131  of  bit; 

readstate:bit; 

softaddr :bit ; 

mrar :array( 1 6 . . 3 1 ] of  bit 

end 

hsw2  : record 

dbusspare :array[ 0 . .2]  of  bit; 
abusspare :array [ 3 • • 4]  of  bit; 
acpuid :array[ 5 . . 6 ] of  bit; 
mcpuld :array[7 . .8]  of  bit; 
pustate:array[9. . 12]  of  bit; 
tustate:array[ 1 3*  • 16]  of  bit; 
rti:array[ 17. • 19]  of  bit; 

end 

mcpumasic:  register; 
intrmask:  register; 
gpreg:  array[0..7]  of  register; 
end( ‘-record* ) ; 

( •operations 

pflagO.pflagl ,pflag2,pflag3, 
pflag4 , pf lag5 , pflag6 , pflag7 : regular  ; 
busoodmon:  monitor ;( *bus  oode  monitor*) 
wdt  : monitor ;( •watchdog  timer*) 

ilopdet  ; monitor ;( •illegal  opcode  detector*) 
ctrlcomp  : monitor ;( ‘control  comparator*) 
adcomp  : monitor ;( ‘address  and  data  comparator*) 
end-operations*) 

(•end-module*) 

mmumodules ( ‘module* ) 


record 

status  : 
oldriphigh : 
oldriplow  : 
newrlphigh: 
newrlplow  : 
softl  : 
soft2  : 
syndrom  : 
wrprotreg  : 
content  : 


register; 
register; 
register ; 
register; 
register ; 
reg4 
reg4 
reg6 
reg4 
arraytO . 

nexttolastword  :word; 
lastword  : word 
(•contents  of  the  memory  words*) 

modtype  .‘integer  ; (*1 1 -application  memory  module 

00- system  memory  module  0 

01- system  memory  module  1*) 


4093]  of  word; 


sysmodcontents 

record 

hard name : integer ; 
softtable :array[ 0 . . 14]  of 
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reoord 

hardname:array[27. . 31 ] of  bit; 
lost : bit ; 

ppmaaks  record 

dma1maak:array[26. .27]  of  bit; 
dma2mask:array[28. .29]  of  bit; 
aiumaak  :array[30. . 31 1 of  bit; 

end 

hardtable :array[ 1 . . 24]  of 
record 

activeapare:  bit; 
dupinfatart:  array[0..14]  of 
integer; 

duplnfend  : array[0. . 14]  of 
integer; 

aoftname:array[28. . 3 1 ] of  bit; 
ripplerconflguration : 

array[0. .40]  of  bit ; 
aparebit  : boolean 
end 

applicatlonmmu:  integer; 

tranacount :array[0. .laatmodid]  of  integer; 
conatloat  :array[0. . 14]  of  bit; 
loatunit  :set  of  integer; 

end 

end( *-record* ) ; 

(■operations 

datacodoon:  monitor;  (*data  code  monitor*) 
buacodmon  : monitor;  (*bua  code  monitor*) 
analogmon  : monitor;  (*analog  monitor*) 
ayndmon  : monitor;  (*syndrom  monitor*) 
softmon  : monitor;  (*softname  monitor*) 
wrprotmon  : monitor;  (*write  protect  monitor*) 
addralmon  : monitor;  (*address  select  monitor*) 
end-operations* ) 

(•end-module* ) 

ccumodules ( *module* ) 

record 

faul treg : register ; 
abuaapid : reg2; 
dbusspid:  reg3; 
acpuid:  reg2; 
mopuid:  reg2; 
flagl ,flag2,flag3:bit  ; 
end( *-record* ) ; 
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( “operations 

pflagcomp  : monitor; 
wdt  : monitor; 

faulthand  : regular; 
end-operations* ) 


(•program  flag  comparator*) 
(•fault  handler*) 


( *end-module* ) 


dmamodules ( •module* ) 
record 

costO  = record  ( *control/status  register  0*) 
mrar :array[ 1 6 . . 3 1 ] of  bit; 

end 

costl  : register;  ( *control/status  register  1*) 

end( *-record* ) ; 


( *operations 

buscodmon  : monitor 

eobdet  : monitor 

wdt  : monitor 

ifm  : monitor 

end-operations* ) 


(•bus  code  monitor*) 

(•end  of  block  detector*) 
(•watchdog  timer*) 
(•internal  fault  monitor*) 


( *end-module* ) 


siumodule= ( *module* ) 
record 

costO  = record 

mrar :array[ 16. . 31 1 of  bit; 

end 

costl  :register; 

end( “-record* ) ; 


(•operations 

buscodmon  : monitor; 
eobdet  : monitor; 
wdt  : monitor; 

seqdbusmon:  monitor ;( “sequential  data  bus  monitor*) 
synchdet  : regular; 
end-operations* ) 

(•end-module*) 


pumodule  =( “module*) 


record 

status  1 : bit; 

status2  : bit; 

end( “-record* ) ; 


51 


t 

’ 

! 1 

' 

J 

t 


(•operations 

lnvoloon  : monitor;  ('input  voltage  monitor*) 
outvolmon:  monitor;  (*output  voltage  monitor*) 
end-operations* ) 

(•end-module*) 

cumodule  =( ‘module*) 

record 

ccuclamp  : bit; 
mmuclamp  : bit; 
iohtclamp:  bit; 
end( *-record* ) ; 

(•operations 

raddet  : monitor; 
end-operation*) 

(•end-module*) 

tumodule  s( ‘module*) 

record 

statusl  : bit; 
status2  : bit; 
end(*-record*) ; 

(•operations 

voltmon  : monitor; 
clkmonl  : monitor; 
clkmon2  : monitor; 
rtimonl  : monitor; 
rtimon2  : monitor; 
end-operations* ) 

( *end-module* ) 

btmodule  =( ‘module*) 

record 

htstatus  : bit; 
end( ‘-record* ) ; 

(•operations 
comparator :register ; 
end-operations* ) 

(•end-module*) 
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var 

(•system  variables*) 

cpu  : array[0..3]  of  cpumodule; 

mmu  : arrayt 0 . . mmusize]  of  omumodule; 
dmal  : array[0..1]  of  dmamodule; 

dma2  : array[0..l]  of  dmamodule; 

siu  : arrayt 0..1]  of  siumodule; 

pu  : array[0..1]  of  pumodule; 

tu  : array[0..1]  of  tumodule; 

ecu  : ccumodule; 

ou  : oumodule; 

ht  : htmodule; 


(•program  variables*) 

status  : array [ 0 .. lastmodid]  of  bit; 

indictedset  : set  of  integer;  (•softname*) 
reconfcount  : integer; 
sysmodid:  array[0..1]  of  integer; 

temptrans:  array [ 0 .. lastmodid]  of  bit;  (•register*) 

numfound:  integer; 

sparemmm:  integer; 

lastusedmmm:  integer; 

i:  integer; 

J:  integer; 
k:  integer; 

(• *) 

(•utility  procedures/functions* ) 

(• *) 

function  faultcat : integer ; 

(•this  translates  a 4-bit  vector  cpu[ ecu .aepuid ] . hswl . fault_cat 
into  a decimal  faultcat  number*) 
begin 

with  cpu[ccu. aepuid] . hswl  do 

faultcat : =bintodeci( 0 ,0,0,0, fault_cat[ 5 ] , f ault_cat [6 ] , fault_eat[7 ] , 
fault_cat[8 ] ) 

end 

function  id(var  unitid ,moduleno : integer ): integer ; 
begin 

case  unitid  of 

1:(*mmu*)  id:=  1+moduleno; 

2:(#siu*)  id : =25+moduleno; 

3:(#dma1#)  id:=27+moduleno; 

4:(#dma2#)  id : =29+moduleno ; 

5:(#cpu*)  id : =32+moduleno ; 

6:(#abus#)  id : =36+moduleno ; 

7:(#dbus*)  id  : = 40«-moduleno ; 

8:(#ccu*)  id : =46+moduleno ; 

9:(*ht#)  ld:=49+moduleno; 

10:(*cu#)  id  : s52-fmoduleno ; 

1 1 : ( • t u* ) id : *55+moduleno; 
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12:(*pu#)  id : *57+moduleno; 

end  (#case*) 

end 

procedure  settemptrans ; 

(•marks  the  occurrence  of  a transient  fault  in  a temporary  counter 
register*) 
begin 

case  faultcat  of 

12  : begin  (#cat2#) 

temptransC id ( cpuid .acpuid ) ] : si  ; 
temptransC id( cpuid .mcpuid) ] :*1  ; 
temptrans[id(abusid,abu3spid) ] :*1  ; 
temptrans[id(dbusid,dbusspid) ] :*1  ; 

end 

8 : begin  (#cat3a#) 

temptransC id (cpuid, acpuid) ] : = 1 ; 
temptransC id ( cpuid , mcpuid ) ] : * 1 ; 
temptrans[id(abusid,abusspid) ] : = 1 ; 

end 

9 : begin  (•cat3b#) 

temptransC id (cpuid .acpuid) ] : *1  ; 
temptrans[id(cpuid, mcpuid) ] :«1  ; 
temptransC id (dbusid .dbusspid ) ] : * 1 ; 

end 

end  (#case») 

end 


function  lastbususer:integer; 

(•this  converts  cpuCccu. acpuid] .hswl . busarbiter  into  a unitid*) 
begin 

with  cpu[ccu. acpuid]  do 

lastbususer : =bintodeci( 0 , 0, 0, 0, 0, busarbiterC 12], busarbiterC 1 3] )+2 

end 


function  ppusoftname:integer; 
(•identify  the  lastbususer*) 
begin 

case  lastbususer  of 

0: ppusoftname: si  9 (*cpu*); 

1 cppusoftname: si  8 (*siu*); 
2: ppusoftname: si 6 (*dma1*); 
3: ppusoftname: si 7 (■dma2*); 
end  (•case*) 

end 


function  bintodeoK var  bit0,bit1,bit2,bit3,bit4,bit5, bit6 ,bit7 :bit) : 

integer; 

(•this  translates  an  8-bit  vector  into  an  equivalent  moduleno*) 
begin 

bintodecl : sbit7+blt6»2+bit5*2  • 2+bit4»2  • 3-*-bit3*2 ' 4+bit2»2  • 5+bit  1*2  • 6 
♦bit0»2'7 
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end 


function  suspected :integer; 

(■converts  the  right  most  16-bit  of  hswl  into  a decimal  integer*) 
begin 

with  cpu[ ecu. aepuid] . hswl  do 

suspected  : = bintodeci(0, 0,mrar[ 16] ,mrar[ 17] ,mrar[ 18] ,mrar[ 19]); 
if  suspected=15  then 

case  bintodeci( 0, 0, 0, 0,mrar[28] ,mrar[29] ,mrar[ 30] ,mrar[ 3 1 ] ) of 
0: suspected : si  6 (*dma1*); 

1 : suspected : s 1 6 (*dma1*); 

2 : suspected : s 1 7 (*dma2*); 

3:suspected :sl7  (*dma2*); 

4: suspected : s 1 8 (*siu*); 

5: suspected: si 8 (*siu*); 
end  (*case*) 

end 


function  activeppmidC var  unitid : integer ): integer ; 

(•returns  the  id  of  the  active  module  of  a given  PPU*) 
begin 

with  mmu[ sysmodidt 0 ] ] . sysmodcontent . ppmask  do 
case  unitid  of 
3: begin 

if  bintodeci ( 0, 0,0,0, 0, 0, dma 1mask[ 26] , dma1mask[ 27] ) = 1 
then  activeppmid(dmalid) :s0 
else  activeppmid(dmalid) :s1 

end 

4 .‘begin 

if  bintodeci(0,0,0,0,0,0,dma2mask[28] ,dma2mask[ 29] )=1 
then  activeppmid(dma2id) : s0 
else  activeppmid(dma2id) :s1 

end 

2:  begin 

if  bintodeci(0, 0, 0 , 0, 0 , 0 , siumask[ 30] , siumask[ 3 1 ] )= 1 
then  activeppmid( siuid) : =0 
else  aotiveppmid(siuid) :s1 

end 

end  (*case*) 

end 


function  mrusedmmm  :integer; 
begin 

case  lastbususer  of 
dmalid : begin 

with  dma 1 [activeppmid( dmaid) ] . costO  do 
mrusedmmm: s bintodeci ( 0 ,0,0, 0, mrar[ 1 6 ] , mrar[ 17], 

mrar[ 18] ,mrar[ 19]) 

end 

dma2id : begin 

with  dma2[activeppmid( dma2id ) ] . oostO  do 
mrusedmmm: s bintodeci ( 0,0,0, 0,mrar[ 1 6 ] , mrar[ 17], 
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mrar[ 1 8] ,mrar[ 1 9] ) 


end 

siuid:  begin 

with  aiu  [activeppmid(siuid)  J.costO  do 
mruaednam: sbintodeci(0, 0, 0, 0,mrar[ 1 6] ,mrar[ 173, 

mrar[  1 8]  ,<nrar[  19] ) 

end 

end  (*case*) 

end 


function  iamapflag( var  hardmodname , numfound: integer) : boolean; 

var  onecounter: integer; 

begin 

with  mnu[ hardmodname]  do 
begin 

onecounter:sO ; 
soft  1 : snumfound; 
aoft2: snuofound; 
for  i:s0  to  39  do 

if  laatword[i] : a 1 then  onecounter : sonecounter+l 

end 

if  onecounter>  24  or  onecounters24  then 
iamapflag'.syea; 
else  iamapflag : sno 

end 


procedure  findsysmodld( var  numfound :integer ;ayamod[0 .. 1 ]: array 

of  integer) 

(•  Thia  procedure  finda  the  mmu  modules  containing  the  system  map. 
"numfound"  is  an  Integer  which  represents  the  number  of  system 
modules  found.  SyatemCl]  represents  the  hard  name  of  the  system 
module  found,  where  i is  either  0 or  1 corresponding  to  the  first 
or  the  second  system  memory  module  found*) 

(•  instructions  "power  on",  "power  off", "ignore  read",  and 
"ignore  write"  are  assumed  to  be  working  correctly  *) 
var  hardmodname: integer; 
begin 

numfound : =0 ; 
hardmodname: =0 ; 
syamod[0] : =0 ; 
sysmod[ 1 ] : =0  ; 
repeat 

hardmodname: shardmodname+1 ; 

poweron(hardmodname) ; (•  turn  on  the  power  of  the  mmu 

module  with  hard  name  "hardmodname"*) 
if  ismapflag( mmu[ hardmodname ], numfound)  then 

(*  this  will  determine  if  the  mmu  module  with  hard  name 
« "hardmodname",  containes  a system  map.  numfound  is  a 
dummy  soft  name  that  is  temporarily  stored  into  the  soft 
name  registers  of  the  corresponding  memory  module*) 
begin 

sysmod[ numfound] : shardmodname ; 
numfound :snumfound+1 
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end(*then*) 

else  poweroff (mould .hardmodname) ; 
until  hardmodname=24  cr  numfound=2; 

end 


procedure  coldreatart; 
var  l:lnteger; 
begin 

(•find  two  good  mmu  modules*) 
l:s-1;  J:«0; 
repeat  begin 


l:*i+1 ; 

poweron ( mmuid  , 1) ; 
soft1[i] :=J;  soft2[2 ] : =J ; 

if  mmu_hardval( J)  then  begin  sysmodt j] : =1 ; j:=J+1  end 
until  j = 2 or  ismmusize; 
flnddma;  (*flnd  one  good  dma  module*) 

loadsystmem;  (*lnitlallze  the  system  memory  using  the  Information 
In  the  backup  memory*) 

flndppu;  (*flnd  one  operational  module  of  eaoh  ppu*) 
recordppu;  (*record  the  mod  Ids  of  operational  ppu  modules  Into 
the  system  map*) 

flndmmu;  (*flnd  all  the  operational  mmu  modules*) 
reoordmmu;  ('record  the  mod  Ids  of  operational  mmu  modules  Into 
the  system  map*) 

loadapplmem;  ('Initialize  the  application  memory  using  the 
Information  In  the  backup  memory*) 


end 


procedure  makecopy(var  softnaml .hardnaml , softnam2, hardnam2 : Integer) ; 
begin 

hardnam2 : sfindspare ; 

If  hardnam2s0  then  hardnam2 : sflndapplmemuod  ( *find  an  application 
memory  module  to  be  converted  Into  a system  memory  module*) 
with  mmu[hardnam2]  do 
begin 

soft  1 : ssoftnam2;  soft2: =softnam2 

end 

copydupinfo( (*from*)  softnaml .hardnaml , (*to*)  softnam2 , hardnam2 ) ; 

end 

procedure  updatesysmap( var  unltld ,actlveppmld(unltld) ) ; 
begin 

for  1:=0  to  1 do 

with  mmu[ sysmodld[l] ] . sysmodcontent  do 
begin 

case  unltld  of 
dma lid:  J : *26 ; 
dma21d:  J : =2 8 ; 
sluid  : J:s30 
end( *case* ) ; 

if  statusCunitld , (activeppmid(unltid)+1 ) mod  2] 
s working  then 
begin 

if  (activeppmid(unitid)+1 ) mod  2=0  then 
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begin 

ppmaskC j+1 ) : = 1 ; 
ppmaskC  J ) : sO 
end(#-then#) 
else  begin 

ppmaskC  j+1 ) : =0; 
ppmaskC J) :s1 
end( •-else* ) 
end( •-then*) 
else  begin 

ppmaskC  J+1 ) : = 1 
ppmaskC  J) : si ; 
end(*-else#) 

end 

end( •-procedure* ) 

procedure  copydupinfoC var  softnaml .hardnaml , softnam2 , hardnam2 : integer) ; 

(•copies  duplicate  information  from  one  module  to  another*) 

begin 

with  mmu[sysmodid[0] ] . sysmodcontent  do 
for  i : sdupinf start  to  dupinfend  do 
begin 

read(mmu[hardnam1 ] . content [i] , cpu[ ecu .aepuid ] .gpregt  1 ] ) ; 
writeC cpu[ ecu . aopuid ] .gpregC 1 ] ,mmu[ hardnam2 ] .contentCi] ) 

end 

end 

function  mmmsoftnameC var  hardname : integer) : integer ; 

(•find  the  main  memory  module  softname  with  the  given  hardname*) 
begin 

with  mmu[sysmodid[0 ] ] . hardtablef hardname]  do 
mmmsoftname: sbintodeciCO , 0, 0, 0,softname[28] , sof tname[ 29] > 
softname[30] , softname[ 3 1 ] ) 

end 

function  mmmhardnameC var  softname : integer ): integer ; 

(•find  the  main  memory  module  hardname  with  the  given  softname*) 
begin 

with  mmu[ sysmodidCO] ]. sysmodcontent . softtablet softname]  do 
mmmhardname: sbintodeciCO, 0, 0, hardname [ 27] , hardnamet  28] , 
hard name [ 29] , hardnamet  30] , hard name [ 31]) 

end 

procedure  setcat4trans( var  unitid .moduleno: integer) ; 
begin 

case  faultcat  of 
cat3a:  begin 

temptrans[id(abusid,abusspid)  ] : s 1 ; 
temptrans[ unitid ] : si 
end 

cat3b:  begin 

temptrans[ id (d bus id .dbusspid) ] : si ; 
temptrans[unitid] : si 

end 

catM:  temptrans[unitid] : si 
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end( •-case* ) 
end( #-procedure# ) 

function  arbitlocationrinteger; 

<returns  a random  integer  within  the  interval  0 to  4095> 
end 

procedure  pp_test (unit id : integer , hard val : bit ) : boolean ; 
begin 

poweron(unitid,activeppmid(unitid) ) ; 
case  hardval  of 
1:  if  pp_hardval( unitld)  then 
begin 

setcat4trans(unitid) ; 

status! id ( unit id ,activeppmid( unitid) ) ] : sworking 

end 

0:  if  pp_weakval(unitid)  then 

status [id (unit id ,activeppmid(unitid) ) ] : sworking 
end ( #case# ) 

if  status[  id ( unitid ,activeppmid( unitid) ) ]»faulty  then 
begin 

poweroff (unitid ,activeppmid(unitid) ) ; 
poweron( unitid , (activeppmid(unitld)+1 ) mod  2); 
if  pp_hardval( unitid)  then 

status! id(unitid , (activeppmid(unltid)+1 ) mod  2]:sworking 
else  begin 

poweroff (unitid , (activeppmld(unitid)+1 ) mod  2); 
with  mmu[ sysmodid! 0] ] . sysmodcontent  do 
lost unit : slostunit+[ unitid] 
end( #else#) ; 
updatesysmap(unitid) ; 
updateppmask(unitid) 

end 

end 

function  findspare:integer; 
begin 

with  mmu! sysmodid! 0 ]]. sysmodcontent  do 
begin 

i:s1 ; 

findspare : s0 ; 
repeat 

isi+1 ; 

if  hardtable! i] .activespares 1 (•spare*)  then 
begin 

poweron(mmuid , i) ; 
soft1[i] :=15;  soft2[i] : s 1 5; 
if  mmu_hardval( 1 5)  then 
begin 

findspare : si ; 

hardtable[i] . activespare : s0  (•active*) 

end 

else  poweroff (mmuid ,i) 

end 

until  i>23  or  findspareOO 
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end 

end 

procedure  updatetranscount( iounitid , iomodid) ; 

(•this  procedure  increments  the  transient  faults  as  follows.*) 
begin 

for  j:sl  to  lastmodid  do  begin 
for  i:=0  to  1 do 

with  mmu[ sysmodldC i] ] . sysmodcontent  do 
transcountt i] : stranscount[ i]+temptrans[ j] ; 
if  mmu[ sysmodidt 0 ] ] . sysmodcontent . transcountt i] > limit transcount 
then  switch_module  ( •transcountt i]  is  reset,  a spare  module 

is  turned  on  and  then  tested*) 

end 

end 

procedure  reconfsysmod(softnam1 , softnam2 : integer ) ; 
begin 

poweron(mmuid , sysmodidt  softnam2 ] ) ; 

if  refreshable (softnam2, sysmodidt so ftnam2 3 ) then 

begin 

refresh( softnam2 , sysmodidt  softnam2] ) ; 
statust id (mmuid, sysmodidt softnam2] )] :=working; 
copydupinfo( softnaml , sysmodidt softnaml ] ,softnam2, 
sysmodidt  softnam2] ) 

end(*then*) 
else  begin 

makecopy( softnaml , sysmodidt  softnaml ] , softnam2 , sysmodidt  so ftnam2 ] ) ; 
statust id(mmuid , sysmodidt softnam2 ] )] : rworking;' 
constlostt  softnam2] : ryes 
end( *else* ) ; 

record ( softnam2 , sysmodidt  so ftnam2] ) 

end 

procedure  refreconf ( softnaml , softnam2 : integer) ; 
begin 

refresh ( softnaml , sysmodidt  softnaml ] ) » 

statust id ( mmuid , sysmodidt softnaml ] ) ] : r working; 

poweron( mmuid .sysmodt softnam2] ) ; 

if  refreshable(softnam2,sysmodid[softnam2] ) then 

begin 

re fresh ( so ftnam2, sysmodidt so ftnam2] ) ; 
statust id (mmuid , sysmodidt  so ftnam2] ) 3 : = working 
end( *then* ) 
else  begin 

makecopy( softnaml ,sysmodid(softnam1 ] , sof tnam2 , sysmodid 
constlostt  so ftnam2] : ryes; 

status[id(mmuid,sysmodidtsoftnam2] )] : rworking 
end ( •else* ) ; 
record (0 , sysmodt 0] ) ; 
record( 1 .sysmodt 1 3 ) 
end 
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function  acceptable : boolean ; 
begin 

<prepare  an  arbitrary  nuamber  x in  gpreg-  (general  purpose  register) 
1 and  write  x into  an  arbitrary  location  y of  a randomly  chosen 
~ module>; 

<load  x in  y into  gpreg-2>; 

<square  gpreg-2  and  store  the  result  into  an  arbitrary  location 
p of  a randomly  chosen  module  q>; 

Cload  the  content  of  p into  gpreg-3>; 

<if  gpreg-1  • gpreg-2  <>  gpreg-3  then  acceptable  :=  yes 
else  acceptable  : = no> ; 

end 


(• — *) 

(•  module  test  procedures  •) 

(•— — •) 


( • 1 • cpu  test  • ) 

function  cpu_hardval : boolean ; 

begin 

(•part  common  to  both  acpu  & mcpu*) 

gpregt 1 ]: =(gpreg[ 1 ]+gpreg[2] )*gpreg[ 3]  - ( gpregt 1 ] “gpregt 3] 

♦gpregt 2 ] *gpreg[ 3 ] ) ; 

if  gprerg[1]=0  then  begin  pflag6;  pflag7  end; 

(•mcpu  comparator  test*) 
for  i=24  to  31  do 
begin 

with  cpu[ccu.acpu]  do 

set(mcpumaskti] ) (set  bit  position  i of  mcpu  mask  register*) 
end ; 

<bus  code  monitor  test> 

end 

function  cpu_weakval rboolean ; 
begin 

if  gpregt 1 ]+gpreg[2]>0  then  begin  pflag6;  pflag7  end; 
with  cpu[ ecu. acpu]  do  set(mcpumask[ i] ) 

end 

(•  2.  bus  test  •) 

function  bus_val :boolean;  (•  use  the  following  three  test  patterns 

to  put  one's  and  zero's  on  each  wire  of  bus. 
monitors  in  cpu  will  detect  the  bus  fault.*) 

begin 

with  ecu  do 
begin 

pflag6; 

for  i:s1  to  bustestreptition  do 
begin 

storehard( ' 0 ' (“module' s hardname  to  be  stored  to*), 

'0000' (*abus*) , '00000000' (*dbus*) ) ; 
if  flag2=0  then 

begin  bus_val:»no;  go  to  100  end 
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3torehard( 'O' , ' FFAB ' , ' FFABFFFF ' ); 
if  flag2s0  then 

begin  bua_val:»no;  go  to  100  end 
atorehard ( ’ 0 ’ , ' F9F4' , 'F9F4FFFF' ) ; 
if  flag2=0  then 

begin  bua_val:=no;  go  to  100  end 
end; 

bus_val : syea 

end 

100: 

end  ( •procedure* ) 

(•  3-  memory  module  teat  *) 

function  mmu_weakval( var  sof tname , hardname : integer ) ; 

var  location : integer ; 

begin 

with  mmu[ hardname]  do 
with  cputccu.acpuid]  do 
begin 

atorerippler ( ao f tname .hardname) ; 

location : sarbitlocation ; (*random  location  between  0 and  4095#) 
read( ccntent[ location] ,gpreg[ 1 ] ); 
write(gpreg[ 1 ] , content [ location] ) ; 
read( content [location] ,gpreg[2] ) ; 
if  gpreg[ 1 ]=gpreg[2]  then 
readwrite_val : =yea 
elae  readwrite_val : =no 

end 

er.d 

function  nmu_hardval( var  softname , hardname : integer) : boolean ; 
begin 

atorerippler ( aof tname, hard name) ; 
if  (readwrite_val( hardname)  and 
datacodmon_val ( hardname)  and 
addrcodmon_val( hardname)  and 
buacodmon_val( hardname)  and 
ayndmon_val( hardname)  and 
aoftnamemon_val( hardname)  and 
wrlteprotmon_val( hardname)  and 
analogmon_val( hardname)  and 
addraelmon_val( hardname) ) then 
sysmod_val : =yea 
elae  syamod_val : =no 
end 

v • 4.  peripheral  teat  •) 

function  pp_weakval( var  ppid : integer ): boolean ; 
begin 

(•aend  a dummy  command  through  peripheral  to  the  correaponding 
control  word.  •) 
caae  ppid  of 

2:(*siu  •)  store( 'F845' (•control  word  1 in  aiu* ),' command ') ; 
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3 : ( *dma1*)  store ( ' F8H1 ' , ' command ' ) ; 

4: ( *dma2*)  store ( ' F843 ' , 'command ' ) ; 
end ; 

If  endofblock( ppid)  then 
pp_weakval :=yes 
else  pp_weakval : =no 

end 

function  pp_hardval( var  ppid : integer ): boolean ; 

function  commonpart_val(ppid :integer) ; 
begin 

if  pp_weakval( ppid)  and 
wdt(ppid)  and 

ifm_val(ppid)  (^internal  fault  monitor*)  and 
buscodmon_val(ppid)  then 
commonpart_val : = yes 
else  commonpart_val : ano 

end 

begin 

case  ppid  of 

2:  if  commonpart_v,al  and  seqbuscodmon_val  then 
pp_hardval : =yes 
else  pp_hardval : =no; 

3'-  pp_hardval : =commonpart_val ; 

M : pp_hardval : =cpmmonpart_val 

end 

end 

(• •) 

(•functional  and  monitor  test  procedures  within  an  mmu  module*) 

(• *) 

(•address  decoder  test  procedure*) 

function  addrcodmon_val( var  moduleid : integer ): boolean ; 
begin 

pflag5 ; (*set  flag  2*) 
ezpara ; 

(•arm  the  enabl  zero  address  parity  hard  address  function  which 
forces  zero  parity  as  the  input  address  parity*) 
read (mmu[ moduleid] . arbtword , cpu[ ecu .acpu] . gpreg[ 2] ) ; 

(•after  the  read  action,  if  the  address  decoder  is  working 
properly,  a fault  interrupt  would  have  been  generated  and  ecu 
flag  2 reset.  •) 
if  ccu.flag2=0  then 
addrcodmon_val : = yes 
else  begin 

pflag7  ; (*reset  flag  2*) 
addrcodmon_val : sno 
end; 

amre set (moduleid) 

end 


(•write  protect  monitor  teat  procedure*) 

function  wrprotmon_val( var  moduleid : integer ): boolean ; 
begin 

pflag5  ; 

ldwp(moduleid , arbtword)  ; 

(•eatabliah  a write  protect  region  aaaociated  with  the  location  of 
arbtword,  using  the  load  write-protect  hard  address  function^) 
write(mmu[moduleid] . arbtword , cpu[ ecu .aepu] .gpregt 1 ] ) ; 

(•if  the  region  is  protected,  a fault  Interrupt  would  have  been 
caused  by  the  write  afction  and  ecu  flag  2 reset*) 
if  ccu.flag2=0  then 
wrprotmon_val : »yes 
else  begin 

pflag7  ; (•reset  flag  2*) 
wrprotmon_val  :mo 
end ; 

amre set (moduleid ) 

end 

(•soft  name  monitor  validatln  procedure*) 

function  softmon_val( var  moduleid rinteger) boolean; 
begin 

pflag5  ; 

ldsftn(moduleid)  ; 

(•establish  different  soft  names  in  the  two  soft  name  registers 
with  the  set  soft  name  hard  address  function  •) 
read (mmu[ moduleid] . arbtword ,cpu[ ecu. acpu] . gpregt 0] ) ; 

(•if  the  soft  name  monitor  works  properly,  a fault  interrupt  would 
have  been  generated  by  the  read  action  and  the  ecu  flag2  reset*) 
if  ccu.flag2=0  then 
softmon_val : =yes 
else  begin 

pflag7  ; (#reset  flag  2*) 
softmon_val : =no 
end ; 

amre set (moduleid) 

end 

(•procedure  for  data  decoder  test*) 

function  datacodmon_val( var  moduleid : integer) : integer ; 
begin 

pflag5  ; 

read (mmu[ moduleid] .arbtword ,c put  ecu. acpu] .gpregt  2] ) ; 
sbpdo( badword ) ; 

(•use  the  store  with  bad  parity  data  instruction  to  put  the 
improperly  coded  information  on  the  bus*) 
pflag5  ; 

ebadpard(mmu[moduleid] .arbtword)  ; 

(•  arm  the  mmu  enable  bad  patity  hard  address  function 
to  permit  the  information  to  be  stored*) 
read(mmutmoduleid] . arbtword , eput ecu .acpu] .gpregt 3] ) ; 

(•if  data  code  monitor  works  properly,  above  read  action 


would  have  caused  a fault  interrupt  and  reset  ecu  flag  2*) 
if  ccu.flag2=0  then 
datacodmon_val : =yes 
else  begin 

pflag7  ; ('reset  flag  2*) 
datacodmon_val : sno 
end ; 

amreset(moduleid) ; 

write (nunu[moduleid ] . arbt word, epu [ecu. epu] . gpregt  2 ] ) 

(•put  the  original  word  back  to  the  same  location*) 

end 

(• •) 

(•  begining  of  the  main  program  •) 

(• - •) 

begin 

with  ecu  do 

with  cpu(acpuid]  do 

ensure  acceptable  ('acceptance  test*) 
by 


(* *) 

(•primary  recovery  procedure*) 

(• •) 


begin 

(•validation  of  epu's  capability  of  reading  HSW1*) 
for  i:s5  to  8 do 

if  hsw1.fault_cat[l]s1  then  begin  pflag6;  pflag7  end; 

(•if  one  of  the  epu  modules  is  faulty,  then  the  ecu  may  receive 
a program  flag  from  only  one  epu  module*) 

(■initialization:  clear  status,  temptrans,  A indictedmoduleset* ) 

for  i:*0  to  lastmodid  do  begin 

status[i] : * faulty; 
temptransCi] : *0 

end 

skip3: «no ; 
indictedset : *[  ] ; 
for  i:«0  to  14  do 
constlost[i] : >no ; 

(•trust  all  TMR  units  and  other  automatically  recovering  units*) 

(•CPU  test*) 

if  faultcat»cat2  then 
begin 

if  cpu_hardval  then 
begin 

status[id(cpuid,acpuid) ] : sworklng; 
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3t»tua[id(opuid,mopui<l)  ] : sworking; 

If  hawl .statechange  s no  then 
f]  begin 

if  bua_val  then 
begin 

atatus[ id(abuaid , abuaapid) ] : sworking; 
atatua[id(dbuaid ,dbuaapid) ] : sworking; 
i_J  akip3:=y«a; 

aettemptrana 

end 

end 

end 

('failure  in  cpu-hardval  will  reault  in  a cpu  reconfiguration 
and  reentry  of  the  recovery  program*) 
end 
elae 

if  cpu_weakval  then 
begin 

atatua[ id(cpuid , acpuid) ] : sworking; 
atatus[id(opuid,mcpuid) ] :=working 
end ; 

(*bua  teat*) 

if  skip3*no  then 
begin 

reconfcount : >0 ; 
while  not  bua_val  do 
begin 

reconfcount : sreconfcount+1 ; 
if  reconfcount>23  then 

cycle_cpu  (*thia  will  cauae  a fault  interrupt*) 
elae  begin 
pflag6; 
cyele_abua; 
cycle_dbua; 

' pflag7 

end 

end 

atatua[ id ( abusid , abuaapid) ] : sworking; 
if  (hawl.atateohangesno  and  faultcatsoat3a  and 
reconfcountsO ) then 
begin 

if  laatbuauaerscpuid  then  aettemptrana 
elae  indictedaet : sindictedaet 

+[ppuaoftname( *laatbususer* ) ] 

end; 

atatua[id(dbuaid .dbuaapid) ] : sworking; 
if  ( hswl . atatechangesno  and  faultcatscat3b  and 
reconfcountsO)  then 
caae  hawl . readatate  of 
1 ( *read* ) : indictedaet sindictedaet 

+[ suspected ( *haw1 .mrar*) ] ; 

0(  "write*  ) : if  .laatbuauaerscpuid  then  aettemptrana 
elae  indictedaet rsindictedaat 

+[ppuaoftname( *laatbususer*) ] 
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end( •case* ) 


(•turn  the  peripheral  units  and  mmu  off*) 

if  ( lastbususersdma lid  or  lastbususersdma2id  or  lastbususerssiuld) 
then  lastusedmmmzsmrusedmmm; 
for  i:=1  to  mmusize  do 
poweroff (mmuld.i) ; 
for  i:=1  to  2 do 
begin 

poweroff (dffla lid , i) ; 
poweroff(dma2id,i) ; 
powerof f ( siuid , i ) 
end ; 

(*cat4d  test*) 

if  faultcatscatUd  then 
begin 

if  lastbususerscpuid  then 

indie ted set : s indie tedset+C  suspected ] 
else  begin 

indie ted set : =indictedset+[3uspectd] ; 
indie ted set : s indie tedset+Cmrusermmm] 

end 
end ; 

(•find  the  system  memory  modules  •) 

findsysmodid( numfound , sysmodid) ; 

(•system  map  recovery*) 
case  numfound  of 

0:(*no  system  memory  module  found*) 
begin 

coldrestart ; 

go  to  1000  (•end  of  program*) 
end; 

1:(*only  one  system  memory  module  found*) 
begin 

poweron(mmuid ,sysmodid[ 0] ) ; 
if  mmu_hardval(0 ,sysmodid[0] ) then 
begin 

status[ id(mmuid , sysmodid [ 0] ) ] : sworking; 
makecopy( 0, sysmodidCO] , 1 , sysmodid [ 1 ] ) ; 

(•using  the  memory  module  with  soft  name  0 and 
hard  name  sysmodidCO]  create  the  other  system 
memory  module,  assign  the  soft  name  of  newly 
made  system  memory  module  to  1 and  assign  the 
hardname  of  the  module  to  sysmodidC 1 ]•) 
record( 1 , sysmodidC 1 ] ) ; 
constlostC 1 ] : syes; 

s tat us [ id (mmuid , sysmodidC 1 ] ) ] : sworking 

end 

else 
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if  refreshable(0,sysmodidCO] ) then 

(•is  the  module  with  soft  name  0 and  hard  name 
sysmodCO]  refreshable  ??•) 
begin 

refresh(0,sysmodid[0] ) ; 

(•refresh  the  module  with  soft 
name  0 and  hard  name  sysmodidC 0]*) 
status [ id (mmuid ,sysmod[0] ) ] : = working; 
makecopy ( 0 , sysmodidC 0 ] , 1 .sysmodidC 1 ] ) ; 
record (O.sysmodidCO] ) ; 
reoord( 1 , sysmodidC 1 ] ) ; 
eonstlostC 1 ] : syes; 

statusC id (mmuid , sysmodidC 1 ] )]  : sworking 

end 

else  begin 

poweroff (mmuid, sysmodidC 0] ) 
coldrestart ; 

go  to  1000  (#end  of  program*) 

end 

end ; 

2:(*both  system  memory  modules  are  found*) 
begin 

poweron( mmuid , sysmodidC 0 ] ) ; 
if  mmu_hardval(0 ,sysmodid[0] ) then 

statusC id (mmuid , sysmodidC 0] ) ] : sworking 
else  poweroff (mmuid, sysmodidC 0] ) ; 
poweron ( mmuid , sysmodidC 1 ] ) ; 
if  mmu_hardval( 1 , sysmodidC 1 ] ) then 

statusC id (mmuid , sysmodidC 1 ] ) ] : sworking 
else  poweroff (mmuid , sysmodidC 1 ] ) ; 
case  status[id(mmuid,sysmodidCO] )]  of 
working : 

case  statusCid(mmuid, sysmodidC 1 3) 1 of 
working: ; ( ^perfect*) 
faulty  rbegin 

rerconfsysmod(0, 1 ) ; 

refresh( 1 , sysmodidC  ID); 

record( 1 , sysmodidC ID); 

statusC id (mmuid , sysmodidC 1 ] ) D : sworking 

end 

end( •ease*) 
faulty: 

case  statusC id (mmuid , sysmodidC  1 ]) ] of 
working :reconfsysmod(  1 , 0) ; 
faulty  : 
begin 

poweron (mmuid , sysmodidC 0] ); 
if  refreshable(0,sysmodidC0] ) then 
refreconf(0, 1 ) 
else  begin 

poweroff (mmuid , sysmodidC 0] ) ; 
poweron(mmuid , sysmodidC 1 ] ) ; 
if  refreshable( 1 , sysmodidC 1 ] ) then 
refreconf ( 1,0) 

else  begin  coldrestart;  go  to  1000  end 


A'* 

i ...» 


68 


end 

end 

end(*ca3e*) 
end( *case* ) 

end 

end( •case*) ; 

(•  store  the  proper  soft  names  of  system  memory  modules  Into  the 
corresponding  soft  name  registers*) 

case  mmmsoftname( sysmodldCO] ) of 
0:  begin 

mmu[sysmodid[0]] .soft1=0; 
mmuC sysmodldCO ] ] . soft2=0; 
mmuCsysmodidC 1 ] ] . soft  1 = 1 ; 
mmuCsysmodldC 1 ] ] . soft2=1 
end ; 

1 : begin 

mmu[ sysmodldCO ] ] . soft  1 = 1 ; 
mmuC  sysmodldCO] ] . so ft 2=1 ; 
mmuC  sysmodldC 1 ] ] . soft  1 =0 ; 
mmu[ sysmodldC 1]]. soft 2=0 
1 : sconstlostt 1 ] ; 
constlostC 1 ] : =constlostC 0 ] ; 
constlostfO] : =1 ; 

end 

end(*case*) ; 

(•dmal  test*) 

with  mmu[ sysmodldC 0 ]]. sysmodcontent . ppmask  do 
begin 

If  dma1mask[26]=0  and  dma 1maskC27]=0  then 

(*thls  oannot  oocur  under  norma1  circumstances*) 
begin  coldrestart;  go  to  1000  end; 
if  dma1mask[26]  <>  dma1maskC27]  then 
begin 

if  faultcat=cat4a  or  16  in  Indictedset  then 
pp_test(dma1id , (*hardval:=*)yes) 
else  pp_test(dma lid , ( *hardval : =*)no) 

end 

end; 

(*dma2  test*) 

with  mmuC sysmodldC 0 ]]. sysmodcontent . ppmask  do 
begin 

if  dma2maskC28]s0  and  dma2maskC 29]=0  then 
begin  coldrestart;  go  to  1000  end 
if  dma2maskC28]  <>  dma2mask[29]  then 
begin 

If  faultoatscat4b  or  17  in  indictedset  then 
pp_test(dma2id , ( *hardval :»*)yes) 
else  pp_test ( dma21d , ( *hardval : =*)no) 

end 

end; 


(•aiu  teat*) 

with  mmuCaysmodidCO]] . ayamodcontent. ppmask  do 
begin 

if  siumaakt 30]«0  and  aiumaskC  3 1 ] «0  then 
begin  coldreatart;  go  to  1000  end; 
if  aiumaak[30  <>  aiumaak[31]  then 
begin 

if  faultcatacatUc  or  18  in  indictedaet  then 
PP_teat( aiuid , ( •hardval : «#)yea) 
elae  pp_teat(aiuid , ( •hardval :s')no) 

end 

end 

(•recovery  of  the  application  memory  modulea*) 

for  i:=2  to  1U  do  (#aoft  name*) 
begin 

J :=mmmhardname( i) ; 

poweron(mmuid , J ) ; 

mmu[ J] . aoft  1 : si ; 

mmu[ J] . aoft2: si ; 

if  1 in  indictedaet  then 

begin 

if  mmu_hardval(i, J)  then 
begin 

atatua[id(mmuid, J) ] : sworking; 
setcat4trana(mmuid , j ) 

end 

end 

elae 

if  mmu^weakvalCl, J)  then 

atatua[id(mmuid , j ) ] : sworking; 
if  atatua[ id(mmuid , j ) jsfaulty  then 
begin 

if  refreahabled, J)  then 
begin 

refreahaomd,  j ,k) ; (*if  there  la  no  apare  module  which 
can  be  aaaigned  to  aoftname  i,  then 
k ia  aet  to  'no'  on  return*) 

if  ksyea  then 
begin 

recordd , J ) ; 

s tat us [ id ( mmuid , j ) ] : sworking 

end 

elae 

for  k:s0  to  1 do 

mmu[ ayamodidC  k] ] . ayamodcontent . aofttable( i) .lost 

: si 

end 

elae 

for  k:s0  to  1 do 

mmu[ayamodid[k] ] . ayamodcontent . aoft table ( i) .loat:s1 

end 

end; 

recover_ayatmemconat ; (*reeover  ayatem  memory  constant  info 
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that  has  not  been  recovered*) 

recover_applmemlost ; ('recover  application  memory  modules  that 

have  not  been  recovered*) 

(•update  transient  fault  count*) 
updatetranscount ; 

1000: 

end( ^primary* ) 
else-by 


(• — *) 

(•alternate  recovery  procedure*) 

(• •) 


begin 

(•validation  of  cpu's  capability  of  reading  hswl*) 
for  i:=5  to  8 do 

if  hswl . faul  t_cat[  i]  = 1 then  pflag6;  pflag7  end; 
(•initialization* ) 

for  i:=0  to  lastmodid  do  status[ i] : sfaulty ; 
for  i:s0  to  14  do  constlostC i] : =no ; 

(*cpu  test*) 

if  cpu_hardval  then 
begin 

status[ id( cpuid ,acpuid) ] : = working ; 
status[id(cpuid ,mcpuid) ] : sworking 
end ; 


(•bus  test*) 

reconfcount : =0 ; 
while  not  bus_val  do 
begin 

reconfcount : sreconfcount+1 ; 
if  reconfcount>23  then  cycle_cpu 
else  begin 
pflag6 ; 
cycle_abus ; 
cycle_dbus ; 
pflag7 
end( *else* ) 
end ; 

status [ id(abusid , abusspid) ] : sworking; 
status [ id ( dbusid , dbusspid) ] : sworking; 


(•turn  the  peripheral  units  and  mmu  off*) 
for  i:s1  to  mmusize  do 
poweroff (mmuid , i) ; 
for  i:s1  to  2 do 


begin 

poweroff(dma1id , i) ; 


L 
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poweroff (dma2id ,i) ; 
poweroff(aiuid,i) 

] ®nd ; 

{ 

(•recovery  of  peripheral  units  and  mmu*) 
coldrestart; 

end( ^alternate*) 

J 

else-error ; 

start_nornial_prooesaing 
end ( •program*) 
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Appendix  C:  Module  teat  procedures 


Test  procedures  for  several  modules  are  detailed  in  this 
appendix. 

C.1  CPU  module  test 

Due  to  a large  number  of  functional  sections  within  a CPU 
module,  a spectrum  of  tests  can  be  designed  according  to  the  degree 
of  coverage  desired.  To  the  least  extent,  a weak  test  of  CPU  should 
perform  the  following  tasks: 

(1)  Test  of  the  monitoring  capability  of  the  M-CPU:  the  bits  from 
position  24  to  position  31  in  the  M-CPU  mask  register  are  set  to 
cause  miscomparison  of  control  signal  lines. 

(2)  Exercise  of  the  ALU  and  registers  (by  executing  a routine):  The 
result  of  this  routine  should  cause  some  predetermined  program  flags 
to  be  generated  and  sent  to  the  CCU  for  the  comparison  purpose. 

(3)  Bus  code  monitor  test:  pp. 3-145  of  [SI]  (an  improperly  coded 
information  is  established  on  the  bus  using  the  "store  with  bad 
parity  data/address"  instruction;  a fault  interrupt  should  be 
generated  if  the  bus  code  monitor  detects  the  invalid  code). 

A strong  CPU  test  can  perform  more  extensive  exercises  of  various 
funotional  sections  Including  the  address/data  comparator,  the 
control  comparator,  etc. 


C.2  peripheral  module  test 


Since  the  functions  of  the  DMA  units  and  the  SIU  are  similar, 
i.e.  to  serve  as  the  focal  point  of  communication  between  the 
computer  and  the  surrounding  environment,  only  the  DliA  module  tests 
will  be  presented.  A weak  test  of  a DMA  module  can  be  done  simply  by 
sending  a dummy  command  (using  control  word  1)  to  the  DMA  module  and 
then  observing  if  this  command  is  properly  received  by  the  module.  A 
strong  test  can  perform  the  following: 

( 1 ) Weak  test . 

(2)  Watch  dog  timer  test: 

(2.1)  primary:  pp. 3-148  of  [SI]. 

(2.2)  alternate  1:  the  CPU  sends  a reconfiguration  ROM  address  to 
the  DMA  and  command  the  DMA  to  request  data  transfer  from  this 
address.  No  memory  module  will  respond. 

(2.3)  alternate  2:  arm  one  memory  module  with  ignore  write  and  cause 
the  DMA  to  send  data  to  this  memory  module. 

(3)  Bus  code  monitor  test:  pp. 3-145  of  [SI]. 

C.3  MMU  module  test 

Each  memory  module  must  be  at  least  checked  for  Its  capability 
to  read  and  write  and  the  correctness  of  its  rlppler  registers.  Thus 
a weak  test  should  perform: 

(1)  Test  of  the  memory  read/write  capability:  a word  is  read  from  an 
arbitrary  location  in  the  memory  into  a CPU  register  and  then  written 
back  into  the  same  location. 

(2)  Verification  of  the  rippler  register  content  against  the 
information  stored  in  the  system  map. 
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A strong  memory  test  can  perform  the  following: 

( 1 ) Weak  test . 

(2)  Write  protect  monitor  test: 

(2.1)  primary:  pp. 3-146  of  [SI]. 

(2.2)  alternate:  for  each  of  the  four  protected  regions  attempt  to 
read  a word  and  then  write  back  to  the  same  location.  If  any  of  the 
blocks  is  protected,  a write  protect  violation  would  have  been 
generated.  If  not,  set  write  protect  for  each  of  the  four  blocks  in 
sequence  and  then  do  read  and  write  operations  for  each  block  to 
cause  an  interrupt. 

(3)  Soft  name  monitor  test: 

(3.1)  primary:  pp. 3-146  of  [SI]. 

(3 .2)  alternate:  use  memory  monitor  test  functions  CSSU.ZCON,  and 
ZCOFF  to  validate  this  monitor. 

(4)  Syndrome  monitor  test: 

(4.1)  primary:  pp. 3-146  of  [SI]. 

(4.2)  alternate: 

a)  reconfigure  bit  lines  and  store  two  calculated  words  in  any 
locations . 

b)  go  back  to  the  original  bit  line  configuration  and  read  the 
first  word.  This  should  generate  a fault  and  cause  syndrome 
monitor  register  to  be  filled. 

c)  enter  refresh  mode  and  read  the  second  word. 

d)  the  second  word  will  generate  another  syndrome  different  from 
the  first  one. 

e)  syndrome  fault  will  then  be  indicated. 

Note:  these  two  words  should  be  so  prepared  that  each  will  cause  one 
bit  error  in  different  positions  when  the  original  bit  line 
configuration  is  used. 

(5)  Bus  code  monitor  test:  pp. 3-145  of  [SI]. 

(6)  Analog  monitor  test:  pp. 3-146  if  [Si]. 

(7)  Data  decoder  test:  pp. 3-145  of  [SI]. 

(8)  Address  decoder  test:  pp. 3-146  of  [SI]. 
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Abstract : Recovery  block  la  a language  construct  designed  to  support 
structured  Incorporation  of  program  redundancy.  In  order  to 
facilitate  a study  on  the  use  of  design/program  redundanoy,  often 
called  fault-tolerant  programming,  a software  that  translates  a 
program  written  In  PASCAL  augmented  with  the  recovery  block  Into  an 
equivalent  program  in  ordinary  PASCAL,  was  developed.  The  translator 
itself  is  written  in  PASCAL.  The  translation  strategy  and  the 
organization  of  the  translator  are  explained.  The  complete  listing 
of  the  translator  is  given  together  with  some  test-run  outputs. 
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1.  Introduction 


l 

! 


Recovery  block  is  a language  construct  devised  to  support 
redundant  design,  also  called  fault-tolerant  programming,  an  approach 
to  obtaining  a software  tolerant  of  residual  design  errors/ 
inadequacies  [HI].  In  order  to  experiment  with  redundant  design,  the 
recover)  block  was  introduced  into  PASCAL  and  the  result  is  called  a 
fault-tolerant  (FT-)  PASCAL  in  this  paper.  It  was  then  necessary  to 
develop  a translator  of  FT-PASCAL  so  that  the  programs  written  with 
recovery  blocks  could  be  executed. 

There  are  two  approaches  to  translation  of  FT-PASCAL  programs. 
One  is  to  translate  the  programs  directly  into  machine  programs,  and 
the  other  is  to  first  translate  the  programs  into  ordinary  PASCAL 
programs  and  then  translate  the  PASCAL  programs  into  machine  programs 
by  using  already  available  PASCAL  compilers.  The  former  approach  has 
an  advantage  of  producing  more  efficient  machine  programs.  On  the 
other  hand,  the  latter  approach  has  an  advantage  of  being  easily 
transportable.  That  is,  once  a preprocessor  which  translates 
FT-PASCAL  programs  into  ordinary  PASCAL  programs  and  is  a PASCAL 
program  itself,  is  developed,  then  the  preprocessor  can  be 
transported  to  any  installation  equipped  with  a PASCAL  compiler  and 
can  support  fault-tolerant  programming. 

In  this  paper  a FT-PASCAL  preprocessor  is  described.  The 

e 

preprocessor  is  written  in  PASCAL  and  has  been  operational  since  May, 
1978.  In  the  next  section,  several  FT-PASCAL  programs  are  shown 
together  with  functionally  equivalent  (ordinary)  PASCAL  programs. 
The  organization  of  the  preprocessor  is  described  in  section  3 and 
some  possible  extensions  are  mentioned  in  section  4.  The  complete 
listing  of  the  preprocessor  is  given  in  Appendix  A and  some  test-run 
results  are  given  in  Appendix  B. 
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2.  Translation  of  FT-PASCAL  Into  PASCAL 


A PASCAL  procedure  is  recursively  defined  as  a sequence  of 
constant  declarations,  variable  declarations,  (nested) 
procedures/functions,  and  the  body  which  may  be  a simple  or  compound 
statement.  All  the  components  except  the  body  may  be  empty.  An 
entire  PASCAL  program  can  be  viewed  as  a (main)  procedure.  The 
FT-PASCAL  allows  recovery  blocks  to  be  included  in  the  procedure 
bodies.  The  control  flow  implied  by  a recovery  block  can  be 
explicitly  expressed  in  PASCAL  by  using  conditional  statements.  For 
example,  see  Figure  1. 

Basically  a recovery  block  is  equivalent  to  the  following  PASCAL 
construct . 


<save:  save  variables  that  may  be  modified  inside  the 
recovery  block> 

<prim ary  object  block  0. 1> 

if  Acceptance  test>  then  (*exit#)  goto  100; 

<restore:  restore  the  variables  tha*  could  have  been 
modified  inside  the  recovery  block> 

Alternate  object  block  0.2> 

if  Acceptance  test>  then  (*exit#)  goto  100; 

<restore> 

<0 . 3> 


if  Acceptance  test>  then  (#exit#)  goto  100; 
<print-error : print  error  message> 
100:<purge:  purge  the  saved  variable  values> 
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X :=  SQRTA 

(X) 

elae-by 

X :=  SQRTB 

(X) 

else-error 

• 

• 

Figure  la. 

An  FT-PASCAL 

program 

• 

• 

Saving  of  Non-local  Variables  To  Be 

X :=  SQRTA  (X)  ; 

Changed  > 

if  |x2  - xs|  < € then  goto  CONTINUE  ; 


< Restoration  of  Changed  Non-local  Variables  > 

X :=  SQRTB  (X)  ; 

if  |X2  - XS|  < 6 then  goto  CONTINUE  ; 

< Send  Error  Message  > 

CONTINUE  : < Purge  Saved  Variable  Values  > 


Figure  1b.  An  ordinary  PASCAL  program 

equivalent  to  the  program  in  la. 
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The  first  component  in  the  above  PASCAL  construct  is  responsible  for 
saving  the  variables  that  may  be  changed  inside  the  recovery  block. 
Since  the  exact  set  of  variables  that  are  modified  varies  from 
execution  to  execution,  the  preprocessor  must  save  all  the  variables 
that  appear  as  destinations  of  assignment  statements  or  actual 
parameters  of  procedure/function  calls.  A simple  approach  adopted  is 
to  declare  a new  variable,  called  a backup  variable,  for  each  of 
those  variables  (which  may  be  called  main  variables  to  distinguish 
from  backup  variables) , and  then  to  save  the  content  of  each  main 
variable  into  its  backup  variable.  Each  variable  and  its  backup 
variable  must  be  of  the  same  type. 

Since  variables  cannot  be  declared  within  a procedure  body,  the 
above  constructs  need  to  be  implemented  as  a procedure.  If  the 
acceptance  test  fails,  then  the  main  variables  are  restored  to  their 
original  values  kept  in  their  backup  variables.  Note  that  the 
specifications  of  acceptance  test  and  restore  operation  appear 
repetitively  in  the  above  description;  it  is  thus  useful  to  implement 
those  operations  as  two  nested  procedures  that  are  repetitively 
called.  The  purge  operation  in  the  above  description  is  equivalent 
to  discarding  the  backup  variables.  If  the  above  construct  is 
implemented  into  a procedure,  the  purge  is  automatic  on  exit  from  the 
procedure.  Therefore,  a recovery  block  can  be  translated  into  the 
following  PASCAL  procedure,  oalled  a fault-tolerant  (FT-)  procedure, 
and  a calling  statement. 

procedure  FT; 

var  <backup-variable  declarations> 
procedure  SAVE; 

<save  the  contents  of  main  variables  into  backup 
variables> 
procedure  RESTORE; 

<restore  main  variables  by  using  the  contents  of 
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backup  variables> 
function  ACCEPTABLE; 
<acoeptance  test> 

begin 

U SAVE; 

<0  - 1 > ; 

if  ACCEPTABLE  then  goto  100; 
RESTORE; 

<0 . 2> ; 

if  ACCEPTABLE  then  goto  100 


if  ACCEPTABLE  then  goto  100 
<print  error  message> 

1 00 :end 


3.  Organization  of  the  preprocessor 

The  preprocessor  goes  through  one  "analysis"  pass  of  the  source 
program,  n "translation"  passes  where  n is  the  maximum  level  of 
nesting  of  recovery  blocks,  and  a "merge"  pass.  In  pass  1 the 
preprocessor  pi^luces  a compact  representation  of  the  information  on 
program  structure  and  vocabulary.  The  set  of  variables  that  may  be 
changed  inside  each  recovery  block  are  also  recognized  during  this 
pass.  In  pass  2 (i.e.,  first  translation  pass),  the  first-level 
recovery  blocks  (i.e.,  recovery  blocks  not  nested  within  other 
recovery  blocks)  are  translated  into  FT-procedures  and  stored 
together  into  a new  file  called  text-increment-1  while  procedure 
calls  replace  the  recovery  blocks  in  the  source  file.  The 
second-level  recovery  blocks  nested  within  the  first-level  recovery 
blocks  are  not  translated  at  this  time.  The  second-level  recovery 
blocks  (in  file  t ext-increment- 1 ) are  translated  in  pass  3 and  newly 
generated  FT-procedures  are  stored  into  a new  file  text-increment-2. 
Thus  each  translation  pass  processes  only  the  outer-most  recovery 


blocks  contained  in  the  text-increment  file  produced  through  the 
preceding  pass.  After  all  the  recovery  blocks  are  translated,  the 
main  source  file  and  all  the  text-increment  files  containing 
FT-procedures  are  merged.  This  unoptlmized  simplistic  approach  is 

motivated  by  the  simplicity  in  logic  and  the  prevention  of  the  source 
- text  file  from  growing  during  translation. 

The  following  words  are  reserved  for  use  by  the  preprocessor  and 
thus  should  not  be  used  in  source  programs. 

(1)  Any  character  string  of  which  the  first  8 characters  are 
"RB/SA/RS/VT/BV/TP"  followed  by  exactly  6 digits,  where  "/"  denotes 
"or"  . 


(2)  FAULTFLAG. 


4.  Extensions 


The  recovery  block  is  not  the  only  high  level  language  construct 
that  is  useful  in  fault-tolerant  programming.  Horning  et  al  [HI] 
proposed  a recoverable  procedure  that  allows  the  Incorporation  of  a 
speoial  procedure  of  restoring  computation,  i.e.,  a procedure 
different  from  undoing  variable  assignments.  Some  other  possible 
extensions  of  the  recovery  block  are  also  discussed  in  [K1].  The 
current  preprocessor  does  not  support  any  of  these  recovery  block 
extensions . 

As  shown  in  the  outputs  of  test-runs  in  Appendix  B,  the 
preprocessor  attempts  to  indent  the  output  (i.e.,  PASCAL  programs)  to 
a limited  extent.  Although  the  PASCAL  programs  generated  may  be  read 
infrequently,  incorporation  of  a more  thorough  indentation  capability 
into  the  preprocessor  seems  to  be  a worthwhile  extension. 
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Appendix  A. 
FT-PASCAL 


Preprocessor 


the  purpo-.e  or  mis  ppepooce gsdr  is  to  accept  a pascal 

PPOOPAM  ANO  TRAN  .LATE  ALL  IT'j  HCCJVEIY  CLOCK';  1 iM  TO 
PROCEDURES  SUCH  ThAT  THE  OUTPUT  OP  PREPROCESSOR  ilf 
ACCtPTLO  HT  CONVENTIONAL  PASCAL  COMPILE*. 

GENERALLY  IT  WORKS  A'i  FOLLOWS: 


PROGRAM  f 

tNCLUOING  > I 

KcC.HLUCK  I 


por . I 

PROCESSOR  I 
I 
I 


» I PASCAL  I > 

l COMPILER  I 

{ _ _! 


THE  PREPROCESSOR  CONSISTS  OF  TWO  PASSES.  PASS  ONE  SCANS 
THRU  THE  INPUT  PR  OCR  AM  ANO  COLLECTS  SOME  INFORMATION 
INTO  OIFFERENT  TABLES  USCD  IN  PASS  T NO . IN  FACT  PASS  l 
8UIL0S  THt  FOLLOWINGS: 

1.  PROCFDURE/KECOVERT  HLOCK  TREE  where  MAIN  PROGRAM 
IS  TREATED  AS  THE  ROOT  OF  THE  TREt. 

2.  VARIABLE  DECLARATION  TRCE.WhICH  S«40L2PASS  2 TO 
RECOGNI2E  GL 00 AL  AND  LOCAL  VARIAOlES. 

PASS  2 GOES  THRU  THE  INPUT  PROGRAM  AGAIN.  USING  THE 
COLLECTED  INFORMATION  HT  PASS  l.  TRANSLATES  FIRST  LEVEL 
RECOVERY  HLOCK S AND  LEAVES  THE  SECOND. ThlRC ... . LEVEL 
R t C. HLOCK  S AS  THEY  ART.  PASS  2 I>  CALLEC  AS  LONG  AS  THERE 
ARE  MORE  RECOVERY  BLOCKS  TO  3E  TRANSLATED. 

SPECIAL  NOTES 


NONE  OF  THE  FOLLOW  TNG  NOTES  ARE  RESTRICTIONS  TO 
THE  USER.  OY  CHANGING  A • CONST  « CORRESPONDING  TO 
EACH,  FLEX IHlLI T T TS  OBTAINED. 

IDENTIFIER  LENGTH  IS  CONSIDERED  TO  RE  8.  MORE  THAN 
THAT  WILL  BE  TRUNCA TE 0 . ( C AN  CHANGE  THE  • CONST  •). 
LINE  LENGTH  IS  CONSIDERED  TO  RE  BC.  FOR  MOKE  LENGTH 
SHOULC  CHANGE  THE  RELATEO  • CONST  • IN  PROGRAM. 
PROGRAM  LENGTH  HAS  NO  RESTRICTION  AT  ALL. 


f, 

// 
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TEXT  LENGTHHOOS 
NO  OF  PROC=20! 

VO~TOC  LENG  TH=l 00  5 
PIPS  LENGTH=82; 

HASH-PTRS  LENGTH=37S 

line“length=8o; 

ID  LENGTH=8; 

I0~ LEND  2=165 
NO  NESTED  W I TH= 105 
TYPE  LCNGTH=4G  5 
NO  OF  C0MP=53S 
NO-OF~SIMPLE=S05 
NL~VAB  T8L  LENGTH=1 005 

IDTrPE^PACKED  ARRA YC 1 . . TYPE  LENGTH!  OF  CHARS 
TEXT  F I LE=F ILE  OF  CHARI 

TFXT~LINE=ARRAYC1..LINE  LENGTH!  OF  CHARS 
STRING* TrPACKED  ARP  A YC  l • • 4 7 7 OF  CHARI 
STRlNG4'j  = PACKE0  AR  R A YC  1 • • 45  7 OF  CHARS 
STRINGTO=PACKlO  ARRA  YC l . . 30  7 OF  CHARS 
STR:nG27=PACKED  ARRAYC 1 • • 2 7 7 OF  CHARS 
STRINGln=PACKEO  ARRAYC1..161  OF  CHARS 
STR1NG10=PACKED  ARRA YC1.. 107  0?  CHARS 
STRINGS  =PACKLD  ARRA  YC  t . .9  I OF  CHARS 
STKING2C=PACKEU  AKRAYC1..20I  OF  CHAR} 

SIRING"i  = PACKED  ARRAYCI..67  OF  CHARS 
STB ING5=PACKlD  ARPAYCI..57  OF  CHARS 
STP I VG»=PACKED  AKRAYCI..4]  OF  CHARS 
STR lN6i=PACKFO  ARRAYC 1..37  OF  CHAR; 
STRING2=PACKED  ARRAYC1..21  OF  CHARS 
IJENriFI ERaPACKFO  ARRAYC I. .10  LENGYH  7 OF  CHARS 
DCUIILE  ID  =PACK>*D  ARRAYC  l..  ID  LENG  27  OF  CHARS 
LINKAGE  PLACES=i<ECORn 

pos:  integer; 

NAMFJIOENTIFIER 

ENOS 

VD  INFOrRECORO 

vname: i dentifter; 
tcoof: integer; 
t rcoO‘‘ ; in  teger; 

i INDIC: INTEGER 

ENOS 

VD  NOOE=RECORD 

p tk  id  votahle : integer; 
si2C: integers 

PR  NAME  IDENTIFIERS 
father: integer; 
first  -.on:  integer; 
younger  orothtrunteger 

e no  ; 

HASHED  PN  AMt  =RE  C ORO 
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VAR 


PlH  10  PROC  TREEtlNIFGERS 
SEUADF: INTEGER 

end: 

COMPONCNTsRECORD 

LEVELIINTCGERS 

name:  identifier; 
indi : chan ; 
i no;1:  Cham  i 
TCOOE: INTEGER 

END  I 

PROC  *iOOE  = RCCOKO 

pr  rh  name: i ocntifier : 
inDicJtorisining;?; 

PTR  TO  vovoor; integer; 

PTH  TO”;  NO  OCL  : IMTE  i‘"R  • 

no  Tlvir  use j:  integers 
ptR  to  nCvar:integer; 

FATR- RT1NTEGFRS 

first  sjn:integers 
entrytintegeh  j 

LABLE: INTEGERS 

mi  pv  • <*u  a it  i 

YOUNGER  BROTHER: INTEGER 

eno; 

NL  VAKsRECORO 

inoicator:string2; 

PTR  to  votab:inyeger 

end; 

PROC  INFO-RECORD 

INDICATOR : STR ING2 • 

NAME: IDENTIFIER 

eno; 

TEXT1 5F|U£  OF  CHARS 
text2:file  OF  CHARS 

TEXT3. TEXT4,INTXA.INTX5: TEXT  FILES 
TEHP_STHT:aRRATC 1..LINE  LENGTH!  OF  CHARS 
LINKIGE:aRHAYC1..LINE  LENGTH]  of  chars 
bufek: arkayl i . .l  ine  length]  of  char; 
nevtype:arrayci..lTne  LENGTH!  of  chars 
NO  BEW  TYPE *POS  NEV.TYPe: INTEGERS 

inoic.Cnk: integers 

TIPE*Ti:iOTYPE5 

ttp:identifier; 

TOKEN. PREV  TOKEN:STR ING205 

PROC  NAPEITOENTIFIERS 

TXT  PTR  , STMT  NO  . LINE  NO:  INTEGERS 

SYMBOLS  • OELITETERSISE^OF  CHARS 

PROC  RR  TREEIAKKAYC I..NO  OF  PROC]  OF  PROC  NOOES 

NEXT  PRffC  NOOE : I NTEG ER  8 

STACRTARRlTC l..NO_OF  PROC]  OF  PROC  INFOS 


TOP  OF  STACK : INTEGER  S 

hash  tible:arrayci..no  of  proc]  of  hashec  pnames 

HASH  PTRS S ARR A Yt  0 • .HASH  PTRS  LENGTH]  OF  INTEGERS 
HASH  inoex.hi:integers  “ 

VA.R_DCL_TR£E:ARRAYC  I..NO  OF  PROC]  OF  VO  NODES 
VAR  OCL  table:arrayci..vO-tBl  LENGTH]  OF  VD  INFOS 
STRUCTURE  table : ARR A YC 1 . .HO  OF  COUP]  CF  COMPONENTS 

simple  iaBle:arrayci..no  of”si*ple]  of  ioentifieri 
ttpsu.Stt.strt.asfr: inieCERT 
LAST  PROCIIDENTIFIEPS 
NEXT_VO  NODE  .NEXT  VO  ROVMNTEGENS 

nl  vIr  Table : arm  a yti • .nl  var  tbl  lengih]  gf  nl  vars 
NL7AR  cist:arrayci..nl  VBR  TBL  LENGTH]  OF  intebers 

NO_NLOC: INTEGERS 

NL  BUFEK:ARRAYCI..NL  VAR  TBL  LENGTH]  CF  NL  VARS 
NETT  NLIINTEGERS 

VITH~3TACK:ARRAYC 1..N0.NESTE0  WITH. 1. .21  OF  INTEGERS 
VI TH  S'J • TUS:  INTEGER  S 
NEXT  NL  var: INTEGERS 

i87{8?&iiETS»E:m’,,,F,E,‘ 

?ig:t£};ifSia3^ooc*EE,''i"rE<!‘:"‘ 

FATHER  name: IDENTIFIERS 

PROC  C3LL. FIRST  CALL. MORE  VAR. ASSIGNED  VAR.REAO  ASS IGNE OS BO OLE AN l 

ooT.scMt  colon:Booleans  “ 

iotioenttfier; 

St  SSTH INGSS 

fl:stringa; 

AN : 5TK I NGS  5 

rc : stringgs 
ch:char  s 

wc.  l as tnooe: integer; 
stk:ahratci..sj  OF  INTEGERS 
TS.tRR  coor: INIEGER5 

NcLO  MERGE. NECO  MORE  pass: BOOLE  AN S 
OCLTYPf,  SEMI  COCON '.HUOLE  AN  t 
LAsTtLGERROK  .lee:  IN  TEGt  R 1 
COL.L  IM.PVOT.GOTOLAll.SW:  INTEGCR  S 
Ptf S. PR v.fnt: IDENTIFIER  5 
COLMAKCR : IN  TEGER  S 


PROCCOURE  GIVE  T TPE.  (VAR  I TP:  IOE.N  T I F I CR  S VAR  POTR 

i • To  get  The  ty ul  of  a component  of  ;om-;  - 

STRUCTURE  V AR I ABLE  THI S PROCEDURE  MAY 
HE  CALLED  GIVING  IT  A 'OIMTER  ID  THF 
STRUCTURE  TAMLr..  IT  MAT  NOT  HE  USED  FOR 
SIMPLE  VARIABLES  TYPE. 


(* 
I • 
(< 
<• 


INTCGER I S 


VAR  L.ILOMNTeger; 

begin  ilo::potk; 
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SHIS  PAGE  IS  BEST  QUALITY  PRACTICABLE 
TROM  COPY  FURBISHED  TO  DSC - 


T 


END! 


IFICCTHUC  TUNE  TArtLEt  1L01.IN'JI  = * •)  ANO 
I SIRUCTUHI  MHLEC  ILO  J.  INHJr*  • » I 

tnrN  iyp:s structure  r a -u.tr  jlo i.nam*- 

LLSt  IF  STRUCTURE  I lMLLC  ILO  3.  IHUW  J *S  * 

THCN  HEC,  IN 

L:  = STPIICTU'*C  T AI'LrC  ILO  1.  ICOOE  ! 

, TYP:=SIMPLE_T4HLECL Ji 
END 

ELSE  IF  STRUCTURE  T A OL  r C I L 1 3 • INQl=*A* 

THEN  ITPlrSTRLClURE  T A CLEC ILO ♦ 1 J. NAME 
ELSE  BEGIN 

l:=structukf  tauleciloj.tcode; 
GIVE  TYPF.  UyP.LIS 
eno; 


PASS  ONE 

IN  GENERAL  PASS.l  PERFORMS  THE  FOLLOUINGI 

INPUT  PROGRAM 
I 


PASS  l 


PROC/RB  tree: 

CORRESPONDING  TO  EACH  REC. BLOCK  OR 
WILL  OE  A NOOF  IN  THIS  TREE.  MAIN 
PROGRAM  SITS  AS  THE  ROOT.  DFTAIlS  OF 
EACH  NOOE  CAN  8E  FOUNO  IN  TYPE  CCL  AREA 

VAR  OCL  tree: 

CORRESPONDING  TO  EACH  PROCEDURE  WILL  BE 
A NODE  IN  THIS  TREE. CONTAINING  VARIABLE 
DECLARATION  AREA  FOR  THAT  PROCEDURE. 

BY  A POINTER  TO  VAR  OCL  TABLE  ALL  IHE 
VARIABLES  MAY  BE  FOUND. - 

VAR  OCL  table: 

A PURTION  OF  THIS  TABLE  CONTAINS  ALL 
VARIABLES  DECLARED  IN  IHE  PROCEUURE 
ASSIGNED  TO  THAT  PORTION. 


4.  STRUCTURE  TABLET 

CONTAINS  ILL  STRUCTURE  VARIABLES  EITHER 
OECLARED  AS  A TYPE  OR  VAR.  NESTED 
RECORDS  ARE  SHOWN  BY  LEVEL  NUMBER.  FOR 
MORE  DETAIL  REFER  TO  TTPE  OCL  AhEA. 

5.  OTHER  TABLES  SUCH  AS  ST ACH .HASH  TABLE. 
SIMPLE_TABLE.ETC. 

8ESI0ES.  PASS  I INSERTS  A • !L INKAGE • STATEMENT 
WHERE  LATER  Of) • SOMETHING  IS  GOING  TO  BE 
INSERTED  INTO  THE  TEXT. 


PROCEOURE  PASS_1J 

PROCEOURC  INITIALIZC.PASSII 

HEGstmt  no:=o;  top  of  stack:=i;  next  nl  var:=i;  line  ndjso; 
NEXT- VO  NOOEtslT  NtXT  vo  row:=i;  fltxT  PROC  N00e:=I5 
OELIWETERSItC  ,Y.  .7  •/*.•>•.•<•  ,•»;!  ,»T*f 

'.'t'l'.'I'.'C.'l'i'C't'I'i1  » 15 

symbols: =c  *a*..*e*,*o*. .•■»•,* 

inoic:=o;  hash  index: =i; 

no  new  type:=o;  pos  nfw  type:=-i; 

Rd-NAME:i«RMoooooo,5  -tp  Ua“e :* • r°ao oao i » ; 

FOR  Mi:=0  ro  HASH  P IRS  LENGTH  CO  hash  ptrschi j: -0; 

FIRST  CALL:=TRUEi  RrAD-ASSIGNEC:=FALSET  PROC  CALL : =F ALSE . 
REWRITE! TEXT! ) 5 REWRITE  C TEX  TO) 5 

ius:si;  colmaker:=o; 

PVS:=*SA 000000*5  PRv:=*PSOOOOOO*5  FNT:=*VTOOOOOO *5 

ocl  type.ttrue;  semicolon:  = true5 

GOrOLAB:=l J5T5 

iypsu:=,?;  stt:=i;  strv:=i; 
next  nl:=ij 

ENO  5 

PROCEOURE  PRINT  RESULT! 
var  iuniegeR; 

BEGIN 

f.riteln;  uritelns 

UR  I I LLN«  • ....  HPOCtOURF  ANO  RECOVERY  .'LOCK  TREE  ....*>! 

WR  I I.  LN5WRI  1 1 LN  5 

WKIlLLNC  PROC  NAME*.*  INDICATOR*.*  p T R TO  VO  I REC  * . 

• FNU  OF  OCL*.'  NL  VAR  USED* • • PT»  TO  NLVAR  * . 

• FATHER*, • SON*,'  IR  0 IHE  R • , * •'■WIRY*,*  LAI'L’I 

WRt IILN5 

FOR  i:=l  TO  NEXT_PR0C_N00E-1  00 
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URI  TELNl 


uritelni 

URITELNI 
URI TLLNl 

■RI TELNl 
FOR  I : ■=  1 
UR  t TLLN ( 


PROC  RR  TRCfriJ.PR  RO  NAME.'  , 

proc'kmVrut  i i.inSicitot. 
proc  RH”rRFt'c  i 3«ptr  ro  voncocui. 

PROC~RHT.tr  • c I J.eTMTO"' NO  'JCL  : IS* 

pRoc_RH;rRi;rri  3..‘io  nl n.i  uSeoiu, 
proc  wh“i  ami  i j.ptw  ro  nCvaa:h, 

PROC  RRTRt  ■ C I l.FArnt  Rill  , 

PHOC'ArfTPELC  l 3.F  IHif  SONM, 

PROC  RHTRt'Ff  n.rOUNf.rR  ARC  THER  IS* 

PROC  RPTRFf  C I 3.ENTRT: ll, 

PAOC~KH~T REt  C 1 3. L ABLE  5 M ! 

URI tElnE 

• ....  WAR  DCL  TREE  ....Ml  URITELNI  URITELNI 


PTK  TO  VOTAULE*.' 


FAIRER'. i 


FIRST  SOM.* 


S I2E  * * • 


HR  DIMER*  » I 


PROC  N A W L • * 


uritelni 

URITELNI 
URI  TELNl 
URITELNI 
FOR  i:sl 
URI  TELNl 


uri ieln; 
UHITELNl 
URIIELNl 
FOR  I IT 
URITELNI 


uritcln; 

URITELNI 
URITELNI 
FOR  I IT 
URITELNI 

URITELNI 
URITELNI 
FOR  list 
URITELNI 
URITELNI 
URI TELNl 


TO  NEXT  VO  NOOE-l  00 
V AR  OCL  TRtPCIJ.PTR  TO  NOTABLE, 

vartcl~treecii.siec:i^«»  *, 

WAR  OCL  TREECM.PR  NAME* 

WAH_OCL~TREEC I 3. FATHER:*, 

W AR  JCL  TREfr  IJ. FIRST  S0NI1A. 

WAR  OCLTREEC  I 3.  TO  li.NGE  F URCTMER  1 14  I I 
UilirECNI 

• ....  WAR  OCL  TABLE  ....Ml  URITELNI  URITELNI 

• TCOOE  • * • NAME*.*  TTCOCE*,'  INOICMI 

TO  NEXT  WO  ROU-I  00 
WAR  OCL  TAHCECI I.TCOOEI**'  •* 

WAR  JCLTARLEC  II.WNARE*'  •* 

WAR  DCL~T AfILEC  I I.TTCOOEII. 

WAR  JCL  T ABLEC I 3. INJIC) I 
URITELNI 

' ....  HASH  TABLE  ....Mi  .R I TELNl  URITELNI 

• PROC  NAME • * • PTR  TO  PROC  TREE'*'  SEO  AOR M I.R I TELNl 
TO  HASH  INOEX-I  00 

HA jH  TAHCECI 3. PR  NAME. 

HASH  TAHLEC  I 3.PTH  TO  PROC  TREE. 
hash~tarleci  l.SEQ~AORl I ~ 

URI TELNl 

• ....  NONLOCAL  WAR  TABLE  ....Ml  URITELNIURI  TELNl 

• INOI CA  TOR  • . • TO  WO  TA8LEMI  URITELNI 
TO  NEXT  NL  WAR-1  00 

• ',7L_7AR  TABLEC I 3. INDICATOR,  • 

NL>WAR-rABCfC n.PTR  TO  W0TARI61I 
URTTELfll 

• ....  SIMPLE  TABLE  ....  MI  URITELNI  URITELNI 

TO  STT-I  00  URITELNI'  '.SIMPLE  TAIILEC I 3>  I 

URITELNI 

• ....  STRUCTURE  TABLE  ....MS  URITELNI  URITELNI 

•LEWEL ' . • NAME  ','  ',«  TCOOEMS  URITELNI 


FOR  1S=1  TO  STRT-1  00 

UR  I TELNl  STRUCTURED  ABLEC  I 3. LEVEL:  3.'  *. 

STRUCTURE  TARLEC I 3. NAME,'  ', 

STRUCTURE  TA3LECI3. INOI,*  ', 

ST  A UC TUR E~ T ABLEC I 3.IN02,' 

STRUCTURE~T ABLEC I 3. TCOOE ISIS 
URITELNI  URITELNI 

URITELNI*  ....  NEW  TTPE  POSITIONS' ,POS  NEW  TYPE : 2 > I URITELNI 
URITELNI'  ....  NEU  TTPE  OCL  SI2E='.N0  UEU  TTPEI2II 
ENOS 


PROC_OCL_PROCESSOR 

GOES  THRU  INPUT  PROGRAM  TOKEN  AFTER  TOKEN 
ANO  on  HITTING  A »R0CE0U9E  UILL  00  THE 
following: 

1.  FINOS  ALL  DECLARATIONS  ANO  SAVES  THEM 

2.  GOES  THRU  THE  PROCEDURE  BOOT  ANO 
FINOS  ALL  CHANGABLE  NONLOCAL  WARS 
ANO  STORES  THEM  IN  NL  WAR  TAOLE  10  BE 
USED  IN  PASS 

3.  IN  CASE  OF  NESTEO  PROCEDURES  WILL 
CALL  ITSELF  RECURSIVELY  ANO  OOES  THE 
SAME  THING  AGAIN. 

IN  GENERAL  THIS  PROCEDURE  CONSISTS  OF  THE 
FOLLOWING  PROCEDURES: 

.VAR  OCL  PROCESSOR 

.BOOT  PROCESSOR 

•REC  3L0CK  PROCESSOR... 

. U I TR  PROCESSOR 

.0  T n E R S 


PROCEOURE  PROC_OCL_PROCESSORt 

PROCEDURE  GET  TOKEN  I 
VAR  I . J.P.N: IN TTGER I 


PROCEOURE  SAVE  STMT!  FORUAROl 
PROCrOLRt  Rf  AO~S  T MT I 

war  I. j: integer: 

|IL  ANK  .COME  NT  I BOOLE  AN  l 
BEGIN 

i : = ii 

IF  NOT  COFltNPlin  THEN 
BEGIN 

WHILE  NOT  EOLNMNPun  00 


THIS  PASS  is  BEST  QUALITC  PRACtICAl 
UtOM  QQPI  FIK44LSHES3  M>  DDC 
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FILMED 

4 --7Q. 

BEGIN 

HEAOITCMP  STMICIDS  I S3  > « 1 « 

ENOJ 

MKA.TLNI 

fo.<  j:*i  ro  line  length  cc  temp  sTNrcjjss*  *i 
ENOS 

stmt  nossstmt  no*is  txt  pt»:=u 

HLANKSsTRU) 5 "COM t NT  S tFAlRE  5 
FOR  JS  = l ro  LINE  LENGTH-l  JO 
BEGIN  IF  TEMP  STwrCUlX*  • IKEN 
BEGIN  BL ANK  S sF  AL  >C ! 

IF  ( (TE“P  irFTCjJ=»(*)  ANO 

(T«''*P-'.n*f£j.l  ]=•••»  > THEN 
BEGIN  COMC^ISsTRLES  G3TO  RbOS  CNO 
ELSE  GOTO  H80  S 

ENOS 

ENOS 

aao 

IF  (BLANK  OR  COMENT)  THEN 
BEGIN 

INOICSslS  save  stmts  read  stnt; 

ENOS 

READ  ASSI GNEO: -FALSE S PROC  CALLS-FALSES 
I>SOlCS  = lS 
ENOS 

PROCEDURE  SAVE  ST  NT  S 
VAR  1 1 J: INTEGER  S 
BEGIN 

IF  INOtCs1  THEN  BEGIN  INOICSslS  GOTO  70S  ENOS 
IF  INOICsl  TH?N  BEGIN  UR  I TELA  < TE  X T1  , TEMP  SIMMS 

LINE  NOSsLINE  NO*lT  GOTO  70S 

C un < — “ 


i:si*n 


BEGIN 


ENOS 

i:=is 

WHILE  (TEMP  SIMTCIIs*  «>  00 
FOR  j;sl  TOT-INE^LENGTH  00 
BEGIN 

LINKAGECJISsi  »S  RUFEACJ3S=»  »5 
ENOS 

LINKAGECI 3Ss*t» 5 L INK AGEE 2 3 S= • L • S L INK AGEC 33 S s» t • ; 

linkageCa3:=*n»s  linkagecgi:s»k« s linkagecg3:=»a' s 
LiNKAGren:  = •<■,»  s linkagec«::=*e»  s 
IF  (INOICs?)  ANO  (LNK=A)  (HEN 
URITELNITEXTl. LINKAGE) S LINE  NOSsLINE  N0*18 
GOTO  70S  ENOS 
IF  (INOICsl)  ANO  (LNK=3>  THEN 
BEGIN 

URITELN(TCXT1 .LINK AGE > S 
WRITELNITEXU  .TEMP  S7MT)  5 

bi?S-?oi=LINE-NO*?T 


CNO  S 

IF  (INOICs?)  ANO  (LNKs2)  THEN 
BEGIN 

IF  TEMP  STMTC 1 3= 'B* 

THEN  BEGIN 

BUFERCI 3S=»8» S BLFERC I *1 3S = »T • 5 

TEMP  STMtenss*  *8  TEMP  STNTCI*13ls*  •; 

END 

ELSE  BEGIN 

BUFERCI3:s*E*S  SUFERC 1*1 3:s»L' 5 
8UFFRC I*23Ss*S,5  BUFERC I* 33 Ss»E • 5 
BUFERC I*»3Ss»  »s  BUFERC 1*53! =*0 • S 
BUFERC I *6 35s»7*  S 

FOR  JSsI  TO  I*S  OC  TEMP  STMTCJ3!s»  *5 
ENOS 

UR  I TELN ( TEXT! .BUFER) 5 
URI TELN( TEXT1 (LINKAGE) S 
URI TELN( TEXT1, TEMP  STMTI8 
LINE_N0!=LINE_N0*37 
GOTO  70S 
ENOS 

IF  (IN0ICS2)  ANO  (LNKsl)  THEN 
BEGIN 

FOR  J ! s l TO  10  LENGTH  30 
BUFERC9 JSs'S  * ; 

URI TELN (TEXT  I .LINK  AGE) 5 
URI TELN( TCxri .HUFER)  S 
■ RI  IELN( TEXT1 .TEMP  STMT)5 
LINE  NOSsLINE  N0*37 
ENOS 
7o : s 


HUFERCJ J!sRH_NAMECJli 


eno; 

FUNCTION  I NDEX ( VAR  CHSCHAR  ) ! tNTEGER  S 
(•  LOOK  FDR  TH"  FIRST  SYMQOLsCH  IN  TEMP  STMT  •) 
(•  IF  NOT  FOUNT  RETURN  ZERO,  OTHERWISE  RETURN  •) 
(•  THE  POSH  ION.  •) 

VAR  t S I N I EGER S 
BEGIN 

I.NUCXSS05 

FOR  is: TXT  PTW  TO  LINE  LENGTH  00 
BEGIN 

IF  CHS  If NP  STMtC I 3 THEN 
BEGIN 

INOEXSsIS  GOTO  SOS 
ENOS 
ENOS 
'->>)  S 1 
L NO  S 

FUNCTION  RENIJlLANKt VAR  TXIINTCGEH) S BOOLEAN  S 
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(•  RES  r BL  ANK  GETS  TRUE  VALUE  IF  THE  REST  OF  »> 

(•  Tf.  MP” 3 TP  I STARTING  FROM  TX  IS  MLANK.ELSE  •> 

(•  RETURNS  FALSE.  *> 

var  j:  integers 
IIEGIN 

RF  ST  HLANKtsTRUES 

FOK  3:=TX  TO  LINE.LENGTH  00 

TERR  STMTCJJ  » • • THEN  R E3T_0L  AN<  I *F  »LSE  I 

ENUI 

eno; 

PROCEDURE  FIND  PROC  NAMES  .. 

<«  PREVIOUS  TOKEN  PAS  BEEN  • PROCt  SURE • .F I NO  • > 

(•  T ML  NEXT  TOKEN  WHICH  IS  THE  PROCEDURE  NAME » I 
VAR  I.JtlNTEGERS 

UE°wHILE  (TEMP  STRTCTXT  PTRJs*  • I 00  TXT_PTR:sTxr_PI,,»i: 
j:  = i; 

HE. Pf.A  T 

PROC  NAHEC J1:  = TEHP_STHTC I X T P TR  3 5 

TXT  PTRt^TxT  P H ♦ I S . 

UNTIL  NO  T I TEMP  STMTCTXT  PTR  3 IN  STMBOLSIOKI  J>IO_LENs»TN>  • 
IF  J<IOJ.ENGTH“THCN 

HEGFOH  l:  = J to  10  LENGTH  00  PROC  NAMEC I 3 1 *•  •« 

ENDS 

ENOS 

PROCEDURE  FIND  IDS 

(«  FIND  A TOKEN. TRUNCATE  IDENTIFIERS  WITH  • ) 

(.  MORE  THAN  ID  LENGTH=8.  COMMENIS  AND  •> 

(.  SIRING  ASSIGNMENTS  WILL  BE  RELEASED  HCREO 
VAR  I.JSINTEGERS  _ ... 

PROCEDURE  PASS  COMMENTS! 

VAR  I : INTEGERS 
8EGIN  ISrTxT  PTR*1S 

IF  NOT  REST^BLANKUI  THEN 
BEGIN 

whilecterp  stmtc i 3 — • •>  oo  i:=t»is 

IF  1 1 TF  R P STMTC  I 3=  ' ( • I AND 

<T£NP“$TMTCI.1]=*»*M  THEN 
BEGIN  t:=T*lS 

UN?!*1  << rEMP,STPTCI3=,»»>  ANO 

<TEMP“STHTCt*l3=«»»)H 

| , , 


ENOS 

ENOS 


ENDS 


C*  SKIP  OVER  CORMEN 

txt_ptr:=i*is 


PROCEDURE  PASS  QUOTES; 

VAR  I • J: IN  TEGER S 
BEGIN  I • - o ; 

IF  TEMP  STMTCTXT  PTR.13='»"  THEN  t.'sTKT  FT*;! 

ELSE  IF“TEMP  STMTCTXT  PTR*23=•,,,  THEN  IT= TX T.P TR*2 ; 
IF  IXO  THEN  " 

BEGIN 

i:=i*is  j:=is 

WHILE!  J MOO  2 *0'  00 

BEGIF  TEMP  STMTC I 3* • • •*  THEN 
BEGIN  ” 

'WHILE!  TEMP  STM  TC  I 3s  • * ' * > 00 

begin  j:=j?is  i : = 1*1 ; ends 

ENO 

else 

I*  SKIP  STRING  ASSIGNMENT  •» 

TxT  PTRIslS 

pass  quotes; 

ENOS 

ENDS 

BEGIN 

pass  quotes; 
pass  comments; 

IF  REST  BLANKUXT  PTR)  THEN 
BEGIN  ~ 

SAVE  STMTS  RE AO_STMT S 
eno; 

prev  token;=token; 

TOKEN  la*  •; 

I :sTXT  PTR ; 

! « PASS  OELIMETERS  »)  > 

WHILEHKLINE  LENG TH > AND ( NO  I ( TEMP_STM TC II  IN  ST^'OLSM) 

no  itsT.i; 

IF  INLINE  LENGTH  THEN 
BEGIN 

SAVE  STMTS  RE A0_ STMTS 

I * — IT 

WHILEINOT! TEMP  STM  TC I 3 IN  STMBOLSl)  00  Its!*!! 

ENOS. 

WHlLFCt  ICLINE  LENGTM>AN0(TtNP_STNTCt3  IN  STMBOLSl  ).)0 
BEGIN 

TOKENC  J It  - TEMP  STMTC  I ]S 
t nu  ; 

tx  r PTRUl  5 

FO«“l:s|  to  IB  LCNGTH  CO  I DC  I It- TOKE  NC  IIS 
!F!TOKtNi»TTPE_  •)  THCN  OCL.TTPC S =►  .1  »l  S 
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IF ( TOKENS • ELSC_ERROR 

IF((PREV  TOKENS* ELSE  ERROR 
( TORCH  s*t  NO 


• » then  L»fTPlVrTo!’  :s 
L lNr  n-15 

•!  A’lO 
• ! AN H 


( TEMP  STMTC  TXT  PTRIs*.*!  1 THEN  SEMI  COLON  : sF  AL~.r  ! 


IF<  TtlKk  Nr'PROCFCURF 
< TOKENs'F UNCTION 
( T OKtNs • BEGIN 
(TOKf Ns* VAN 


•»  OK 
•I  OK 

. ....  »»  OR 

(TOkENs*VAH  *»THFN  MORE  VARItFAL'"*'; 

IF(  ( TOKtrji  *REAO  •)  1° 

(TOKENs*READLN  •»»  THEN 

RLAJ  AX'* I GfJE OTsTKUE# 

IF  TEMP  STMTCTXT  PTRJ=*C*  THEN 
BEG  TN 

*HlLE ( TE  MP  STMTCTXT  PTRJ  »*1*»  DO  TXT  PTKIsTXT  oT*»t! 
TXT  PTR‘.sT7T  ptr*u~ 
end;  " 

IF  TEMP  STMTCTXT  PTR  Jr  * . • THEN  C0T:sT»UE 

ELSE  COTJsFALSEI 

IF  TEMP  STMTCTXT  PTR3**;*  THtY  SE'-I  COL  3N : sTRUC 

else  sfmi  colon:sfaloe; 

IF  (READ  ASSIGNED!  ANO  (TEMP  TTMTCTTT  PTR]s**«l  THEN 

~ kead_assigned:=falSEj 

eno; 

PROCEDURE  FIND  TYPE l 
VAR  I •JtK.LTINTEGCR; 

BEGIN 

IF  ( I Ds*ENO  *1  ANO  (COOEsSI  THEN  GOTO  3371 

IF  C0DES5  THFN  CH:s»;t  ELSE  CM:=*s*J 
IF  ( I'iOEX(CHI=01  ANO  (MORE  VAR!  THEN 
BEGIN 

save  stmt;  reao_stmt; 
fino  id; 
eno; 

IF  MO*E  VAR  THEN 
BEGIN 

IF  CODES?  THEN  CH:st;»  ej.se  CHJs»=«;  I IsINOEX (CHI *1 ; 
WH ILE<  TEMP  STMTC I Is • •!  00  l:sl*lj 
l ; = i ; 

WHILE (NOT (TENPSTMTCI3  IN  C*!»»*!*3  !1  00 
BEGIN 

TIPECL llsTEMP  STMTCIIi 
i:si*i5  L;=L*t; 

IF  REST  BLANK! 1 1 THEN  GOTO  83i 

eno; 

as:; 

IF  COOCSO  THEN  TXT  PTR:sI| 

if  ti?eci3=*(*  then  begin  tipecli:s*i*;l:=l*i;end; 
FOK  KIsL  TO  TTPE  LENGTH  CO  T I PEC  K 0 : = • • ! 

FOR  K:sI  to  ID  LEN6TH  DO  T YPC  K 1 5 s f I PEC  K 3! 


FOR  l:=I  TO  3 00 
BEGIN 

STt  I 3:  sTI  PEC  IK  FLCU:sIIPECnt 
ARC  UISTIPECI  3;  RCC  I I:  s 1 1 PEC  III 

eno; 

flca3:stipccaj;arca3:sflcahrcca3:=flc  at; 
arC53:=tipeC53;rcC55:sarC5T;rccsJ:=tipeC63; 
eno; 

S37:; 


& 


& 


& 


(•  MAIN  BOOT  OF  GET  TOKEN  *1 

acciN 

CASE  COOE  OF 
i:  BEGIN 

/■  proc  name:=*out  most*;  prb:s»pr»; 
tokei7:s*proceouHe  •; 

first  call:sfalse; 
save  "tht;  read  stmt; 
eno; 

z:  save  stmt; 

3:  find~io; 
a:  find'proc  name; 

5:  BEGIN  FIDO  101  FINO  TYPE!  ENO*. 

6:  if  rxr  ptr<cine  length  then 

IF  TEMP- STMTC  T XT  PTRJti I • THEN  PROC  CALL 
7:  IF  TXT~PTR<LINE“LENGTH  then 

IF  TrMP-srirCTXT"PTR Js»{ * THEN  PROC  CALL 

9:  find  Type; 

a: 


jsfalge; 

istrue; 


begin 

PSsTXT  PTR-lt 

VMILC(TP>11  ANOUTCmp  STMTCPI  • *3*1  OR 

( TEMP“STM  TC  P J » • C * ! ! ! 00  PjsP-i; 
IF  READ  ASSIGNEO  THEN 

I F ( P?l I OR  ( TFMP  STMTCP]s*3*! 

then  assignCu  var::jrue 
else  assigneo“vat:=false; 

IF  NOT  READ  ASSIGNEO  THEY 
BEGIN 

ch:=»: • ; 

IF  INDEXICH!  « 0 

THEN  ASSIGNET  VAR:*HU£ 

EL  SE  AST.tGNED^VAicrMLSE: 


ENO 

ENO 

ENO 


FUNCTION  HASH  (VAR  10  NAME  .*  I DENT  I F l ER  I : I Mf  3CR FORWARD! 


92 


3 


PROCEDURE  CREATE_PROC  NODE ! 

VAR  I.JSINTEGCRS 

PROCLOURL  F I LL  SON..HHO  THER  8 
VAR  j:IN(LCri<l 

!•  A PROCEDURE  10  AOOFO  TO  PHOC/RB  TRCE 
!»  HOOIFY  THE  LINKS  TO  IIS  HKOIHER  AND 
<•  FATHER. 

BEGIN 

IF  PROC  NAME  i *0UT  ROST*  THEN 
BEGIN 


JJsPROC  RO  TREECNEXT  PROC  NODE J.F A TmCR 5 
IF  PROC” Rl'  TREECJ  I.FTR3T  >ON:0 

THEN  PRiJC  ffH  TRFfCJT.FIRjT  SON:=NEXT  PROC  NODC 


ELSE  BEGIN 


j;=PROC  Rrt  TREiCJl. FIRST  SON! 

WHILE! PROC'RH  TRE'CJ ]. rODNGf R OR  OTHER# A > 00 
jjrPROC  R3  TREECJJ. YOUNGER  BROTHER; 

PROC  RU  TREEC JT. IOJNGER  UROOThCRIs 
“NEXT  PROC  NC0E5 

ENOS 


(.  RAIN  BOOT  OF  CREATE  PROC  NOOE  • I 

UEGulTH  PROC  RB  TREECNEXT _PROC  N00E3  00 
bEGIN 

< • INSERT  THE  NOOE  INTO  TREE  •> 

PR  R ‘i  NAPE  t sPR  OC  NARES 
indicator: sPRrf ; 

PTR  TO  V0N00r.:=NEXT  VO  NOOE  • 

no  7lv*r  useo:io;  ” 

PTR  TO  NCVARtsOS 

first  son:=o; 
younger  rrother:=os 

HARK :=*0* 5 

e.ntrt:sline_no*i; 

IF  PRBS*RB*  then  begin  ladle:=go T0LA9I 

GOTOLAa::GOTOLAU«lOt 

eno 

ELSE  LABLE:=15 

IF  PROC  NAHE=*OUT  ROST*  THEN  FATHER  1 = 0 
ELSE  BEGIN 

(*  LINK  THE  NOOE  TO  I.TS  FATHER  •» 

FATHER  NAMEI-STACxCFRECTTOP  CF  STACK)  J.NA>*E  S 

i : rHA  S3  <f  a then  nare)5 
j:=hash  ptrsciT; 

WHILE! FATHER  NARE  * HASH  TABLECJI.PR  NAREl  00 
BEGIN 

REPEAT  i:s<t*l)  ROO  hash^ptrs^ength; 
UNTIL  (HASH  PTRSCI 3 » 0)1 

j:=hash  ptrsctis 

ENOS 

FATHER:=HASH  TA8LECJJ.PTR  TO  PROC  TREES 
ENOS  " 

ENOS 

FILL  SON  BROTHERS 
NEXT  PROC  NOOEJsNEXT  PROC  NOOEMS 
end; 

PROCEDURE  POP  STACKS 

{»  A PROCEDURE  IS  SCANNEO.POP  IT  *) 

BEGIN 

TOP  OF  STACKI=TOP  OF  STACK-15 
ENOS  ~ ~ 

PROCEDURE  PUSH  STACKS 

<•  A NEW  PROCEOURE  IS  SEEN,  PUSH  IT  •> 

BEGIN 

STACKCTOP  OF  STACK?. INOICATORJsPRSS 
STACK!  r0P“0F“STACK).NA*1E:=PR0C  K ARE 8 
top  of  stickTstop  of  stack.i;  “ 

ENOS  ~ 

PROCEDURE  INSERT  HASH_TABLES 
VAH  j: INTEGER? 

BEGIN 

j:=hashtproc  nare>; 

WHILE1HA3H  PTrRSCJ)  * 0)  00  / 


WHILE!  HASH  PTrRStJ)  * 0)  00  / 

j:=ij.n'Ron  hash  ptrs  lengths 
HASH  P TRSC  J 3: -HASH  TNOEXT  JS-HA  >H  INOEXS 
HASH'INOEX :=H4SH  lSOEX*LS 
WITH'HASH  TAdLECJJ  00 
BEGIN 

PR  NARf;=PROC  NARES 

►HR  TJ  PR)C  TRE E : - PRf 0 ! N*: X I “HCC  NOOEIS 
IF  PROC  NAHEi'OUT  ROST*  THE*  SEG"AJR:sO 

elsi  seg"aor:ssint  no; 

ENOS 

L ASTNOOE I sPRE  0! NF  X I PROC  NOOC)J 

1 ! 


FUNCTION  HASH; 

var  i » j, irN ,sur : integer; 

BEGIN 

(•  U'.ING  THE  ORDINAL  NU*Ml»  IF  SYPBOLS 
!>  AN  J (HEATING  Ini  3 THING  A.  A NLRtlE  R 
! • HASH  THE  STRING. 

i : - 1 1 i-nims  sun:  os 

WHILE!  I < * 1 0 LENGTH)  UO 

lit  Gin 


XHIS  PAGE  IS  BEST  QUALITY  PRACTICABLE 
raOM  QQPY  JTWELSHED  XOBDQ  - ~ 


it 


1 


£8 

9i 


if 

// 

it 


JJsOROdD  NAMECIUS 

IF  J>(,4  THEN  JUJ-G4  FLOE  J JSJ-J2I 

sum:  = ;um.j.t‘:ns  tenuien.iui 

lnoi 

MASHUSUM  MO')  HASH.PTRS  LENGTHS 
ENOS 

PROCEOURE  VAK  DCL  PROCESSORS 
PROCEDURE  NEW  TfPE  NAMES 
var  i : i n i toC« ; “ 

<»  IN  CASl  OF  NESTED  RECOHOS.ANRATfFILE  •) 

<«  SET  ....  A TTPE  OECL  ARA  T I ON  Ml,  IT  RE  •> 

«•  Ok'NEMATEO.  THE  TYr*r  NAME  11  CONS  I DE  RED • > 

(•  TO  ME  TPOOOOOUrPOQOOC.it ...■•> 

BEGIN 

NO  NEW  TYPE : sNO  NEW  TYPE»15 
IrSOROTTP  NAMEtTlI  LENGTH  J)  5 
IF  !=!>/  THEN 
BEGIN 

TP  NAMECIO  LENGTH J:=»0» S 

T P NA  ME*  1 0~ LE  i.GTH-lJt*CHR(S'JCC(flRO(TP  NAMEC  I D_LEfIGTH- IT)  > ) I 
END* 

ELSE  TP  NAMECIO  LENGTH K=CHR( SUCCT CROC  TP  NAMEC 10  LENGTH 0 I ) > S 
ENOS  " 

PROCEDURE  SAVE  SIMPLEIVAR  10 S IOEN T IF  I ER » S 
BEGIN 

SIMPLE  TABLECSTT ):-I0J  STTIsSTT*!; 

ENOS 

PROCEOURE  SIMPLE  OR  RECOPOIVAR  1 1 1 0 J : IN TEGER » 5 
<•  IN  CASE  or  ARKArC  ...I  0F...IIT  MAY  HE  *) 

<»  ARRATC...33F  RECORD.  OR  ARR AYC • • • 3 OF  .) 


<»  ARRAYC...13F  RECORD.  OR  ARRAYC . J OF 
(»  SIMPLE  TYPE. OR  ARRAYC...  )OF  R£C  WHERE 
(•  REC  IS  PREOECLAREO  AS  STRUCTURE  TYPE. 
U JO  IS  A COOE  FOR  RCCOGNUINC  THE  CASES 

<» 

(•  JJ=l  > ARRAYC ....TOF  RECORD 

(.  JJ=2  > ARRAY! ,...3oF  REC 

<*  JJ=S  > ARRAYC .... 10F  SIMPLE 

(.  II  WOULD  HE  A POINTER  TO  REC  IN  THE 

<»  STRUCTURE  TABLE. 

VAR  I .j.k: INTEGERS 

T:  IDENTIFIERS 

BEGIN 

I S” TYPE  LENGTHS 

WHILE!  TTPECI  3 IN  C • '.'SMI  CO  t:sl-ll 
J : - I S 

WHILE  (TIPECJ3  IN  SYMBOLS)  00 
BEGIN  j::j-i; 

IF  J=0  THEN  BEGIN  JSslS  GOTO  US  ENOS 


j:=j*is 

u:  t 

FOR  ICsI  TO  10  LENGTH  00  TCK]:=»  • ; R:*t5 

WHILE!  ( J<-I  ) AHO  (K<=10  LENGIH))  00 
BEGIN  TCK3:=TIPECJIS  k:sk*i;  j;sj*i ; ends 
IF  T= • KECOR 0 * THEN  BEGIN  JJUIS  GOTO  125  ENOS 

wAil£  (K<=STRT-l>  00 
BEGIN 

IF  STRUCTURC.TAULCCK 1. LEVEL <2  THEN 
BEGIN 

if  tsstructure_tableck:.name  THEN 

BEGIN  JJ:  = 25  1 1 : sK ; GOTO  125  END 

ELSE  k:=k«is 

END 

ELSE  k:sk*u 
ENOS 
jj:*3s 

12:  s 

ENOS 

PROCEDURE  HANOLE  AR  ST  FLS 
VAR  t.JSINTEGCfT;  “ “ 

(•  IF  TT PC  IS  SIMPLE  ARRA Y .FILE  . SE T . OR  •» 

U (...)  I HEN  GENERATF  A NEW  TYfC  NAME  ») 

(«  DECLARE  A NEW  TYPE  AND  USE  TnA T*  •) 

BE  GIN 

FOR  IS=1  TO  LINE  LENGTH  DO  BUFERCIJSs*  •! 

NEW  TYPE  NAMES 

FOR"i:s|"TO  IO_LENGTH  00  RIJFERC  IJI  * TP  NAMECI1S 
BUFERCI 5 

FOR  JS  = 1 to  TYPE. LENGTH  00  (JUF£RCI*J*n:rTIPErjJ5 

BUFErfC I »J*1  i:  = *sTs 

WRIIELNITEXTI' tBUFCRIS 

for  j:=i  to  type  length  do  riFfCJ3:s»  *s 

P0R  J15l  TO  I 0_LCMGCH  00  T YPC  4 J:  =TP_N  AMEC  J I } 
t NU  S * 

PROCEOURE  GFNEYATE  OCL  ST"T(VAR  L C .HGI  I N TEGE  R ) 5 
(*  WHEN  A UECCS»;i*  TS  COMPLcTElY  STORED  *> 

(*  IN  STRUCTURE  TAHLE.C«*.ATE  A NEW  T YPr  •) 

(»  NAME  AND  OECCARC  It  AGAIN  . THEN  SAVE  *> 

(•  IT  IN  TEX  12.  .) 

(•  example:  . > 

(•  TPOOOOOliRECORO  .) 

«•  SAME  COMPONENTS  *) 

ENOS  .) 

( • . | 

nar  I, J.K  ,i : iNtrr.F  r; 

BEGIN  T-  * J I ! .!OOLr  AN  S 
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ESDI 


FOR  U = l TO  L INC  LENGTH  DO  HUFEREIJU*  •! 
rc:s*i«ecuro*  ; jTslo;  give  typcuyp.j); 

r OR  JUl  10  10  LENGTH  00  UtFE  AC  J J : a T TPC  J 31 
HUFERC J3:s*s« I 

FOR  Usj»l  TO  J*f,  00  BUFERCMUPCCI-JlS 
WRITELNUEXU.IIUFLR) S 

LO:-LO*JJ  Us  STRUC  TORE  T AHLEC LO 3 .LE VEL S 

WHILE  «L0  <-  HG>  00 

riCGIN 

FOK  j:=l  TO  LINE  LENGTH  CO  8UFCHCJ3:=*  *S 
«•  SKIP  OYER  THE  INN^R  HCCOROS  •» 

I F(  STRUCTURE  T A BL EC  LO  1. LE  VEL s I > THEN 
BEGIN 

lOUSTRUCTUKE  TA  ILECL03.NAME  i JIsLOS 
GIVE  TYPC < TYP7J) ; 

FOR  3: si  TO  10  LENGTH  CO  HUFERC J* IS 3: s ViZ  I I T 
BUFExf J.lBlIs*?*; 

FOR  Ktsl  TO  10  LENGTH  CO  HUFERC J*K* 15  It  - T Y"C K 3 S 
LAST:  s TRUE  i LTsLOMi 

<•  TAKE  CARE  OF  »EF I COLON  FOR  THE  •> 

(•  LAST  COMPONENT  OF  GENERATED 
(•  RECORO  TYPE. 

WHILE  (L<sHG>  00 
OF.  GIN 

IF  STRUCTURE  T A BLEC L 3 .LEVELsI 
THEN  LAST:sF1IlSE! 
l:sl*i; 
eno; 

IF  (NOT  LAST  I THEN  BUFERC 1: : 

WRITELN<  TEXTS. BUrEA ) S 

ENO  l 

lo:=lo«i; 
eno; 

FOR  KIsl  to  line  lfngth  00  BLFERCKIIS*  •; 

BUFERC103:  = »E»;  BUFf.RCU3:s»N';  BUFERCl23:s»0'I 
BUFERC U3:a*S  *S  URITELN(TExr2.8UFER) S 


* > 
• I 


» t • t 


PROCEOURE  HANDLE  RECOROtVAR  I 0! IOEN T IF  I ER > I 
VAR  Il.JJ.I.JTlNTEGERS 
BEGIN 

stkc  rs  i:  sstr  t t rs:ars»ti 

IF  LEVal  THEN 
BEGIN 

CASE  TYPSU  OF 
t:  BEGIN 

(•  CALLED  FROM  TYPE  PROCESSOR 
WITH  STRUCTURE  TABLEC  STRT  3 00 

begin  level:=lev;  naneuio; 

INDUS*  •:  IN02;s*S*5 

tcodeustt; 


• > 


eno; 

neu_type_nahe; 


CALLEO  FROM  VARCCL  PROCESSOR 


IF  IT  HAS  BEEN  ARRAYC • • • 3 OF 
RECORD  .THEN  Rf°LACE  • RRECORO  * 
WITH  A NEW  TYPE  KANE  ANO  USE 


• > 

») 
• ) 
• » 


THIS  NAME  FOR  CREATING  THE  NEW  •> 


DECLARATION. 

example: 

ARRAYC. ..30F  RECORO 
IS  CHANGEO  to: 

ARRAYC. ..30F  TP000002 
TP000002SRCCOR0 


ENCS 


_ 3AVE_SXMPLE(TP  NANEJj 

ENO . “ 

2:  BEGIN 
<• 

(• 

(> 

(♦ 

(• 

<• 

(• 

<* 

(* 

<• 

(• 

(• 

(• 

(• 

(. 

IF  ASFRsJ  THEN 
BEGIN  U = TYPE  LENGTH; 

WHILE( T IPECI 3 IN  C*  * . • * * 3»  00  i:  = [-i; 

WHILEt  T IPEC  J 3 IN  SYMBOLS)  00 

BEGIN  TlPECJUs*  •;  j;sj-lj  CNO! 

NEW  TYPE  NAMES 

FOR  i:  = I“TO  10  LENGTH  00  TIPECI*J3:  = TP  'I4MECI3; 

WITH  STRUCT'JRE_TAHl-.CSTRT3  00 

BEGIN  LcVEL:sCEYS  NAMEJsTP  NAMES 

INOUs*  •;  I NC2  : a * T!  TCOOEUOS 

eno; 

TUsTIPES  GOTO  JARS 
ENOS 

NEW  TYPE  NAMES 

WITH  STRUCTURE  TAHLCCSTRT3  00 
HLGIN  L E Yl*L  J -LF  V S NAME  : s TP  NAMES 
I N02 : s • *T 


*) 
• ) 
*> 
• ) 
• > 
• ) 
• > 
• > 
• ) 


INOU  = * 

Tcooeisos 

ENO 

ENO 

END 

ENO  ELSE 
BEGIN 

NEW  TTPF  NAMFS 

WITH  STROCf'JRE  TAHLFCSTRT3  00 

UfGlN  LEVrL:sCrv;  NAM'.JsIOS  INOUs* 

iNoais’S*;  tco)E:sstt; 

eno: 

SAVE  SIMPLEITP  NAME); 


ENO 
jar:; 


95 


ansPiiQBW 

1W* 


BEST  QUALITY  FRACTICABWI 


: f* 

r .y 


J 


StRT:=OIRf*i;  LCV:=LEV»U 

cooe:=s;  gct  tokeni 

WHILE*  10* 1 END  *1  00 

BEGIN 

IF  URCs^PftCKro*  > OR  C STr  t SC  T • I OR 

<FL=tFlLE»>  OR  (rr?CU5'«MI  THEN 

DC  GIN 

WITH  STRUCTURE  TA HLEC  3 JR  T 3 00 

BEGIN  LEVEL'-sCEV!  NARttsIO;  INDi:**  • 5 

EN0.  lN02:s«St;  TCOOcJsSTT! 

strt:=strt*i{  hanole  ar  st  fu 
„ SAVE.SIHPLEITTP) s goto  1a  tt 
end; 

IF  AR=*  ARRAY*  THEM 
BEGIN 

SJHPLE  OR  RECOROT IltJJIS 
C ASF.  3J  _0F 
IT  BEGIN 

<•  RESERVED  •) 

END! 

a:  begin 

(»  ARRAYC...30F  REC,  REC  PKEOCL  •> 
WITH  STRUCTURE  TABLECSTRT3  00 
BEGIN  LEVEL:=LCv;  NARElsIO; 

inoi:=»  • ; inc2:=»r*j 
TCOOEISII ; 

eno; 

eno; 

3:  BEGIN 

{»  ARRAYC...3  OF  SIRPLE  TYPE 
WITH  STRUCTURE  T AOLCC  3 TR  T 3 00 
BEGIN  LEVFL:=Lrvj  NAREJsIOS 

inoi:=*  •;  ino2:=»s»; 

TCOOE : =STT s 

eno; 

HANDLE  AR  ST  FL S 
ENO  ~ 

eno; 

„ STRT:*STRT*IS  GOTO  JA7; 

eno; 

IF  RC=»RECORO*  THEN 

BEGIN  HANpLE_RECOROIIO) I GOTO  3A7I  ENOI 


• > 


SAVE  SIMPLE* TYP>; 


JJ=2  THEN 
BEGIN 

WITH  STRUCTURE  TACILEC STRT 3 00 

begin  level:=Cev;  nare:=io;  inoi:=*  •; 
i ND2 : r *r • ; tcooe:=ii; 

end  ; 

GOTO  3471 


end; 
with  _ 

BEGIN 


WJTH  STRUCTURE_TABLECSTRT3.Dg 


strt;sstrt*i; 


ENO 


LEVELIsCEV!  NA.ME:  = IO;  IN01 ; st  t{ 

iN02:s*st;  tcooe;sstt; 

eno; 

save  simpletttph 
347;-  get  token; 
eno; 

lev;slev-i; 

i:=strt-i;  j;=stkcts-i3i  ts:sts-i; 

GENERATE  OCL  STHTTJ,I)I 


PROCEDURE  CREATE  VO  NOOE! 

var  i.jiinteger; 


PROCEDURE  FILLUP_SON  BROTHER! 
var  k:integer; 
begin 

IF  PROC  NAME  • 'OUT  ROST • THEN 
BEGIN  “ 

KSsVAR  OCL  TREETNEXT  VC  NOOE 3.F ATHCR ; 

IF  VA R“OCL“  TRt'ECK  J.FTRiT  SONsO 
THEN  VIA  OCL  TRFECK3. FIRST  SON:=NEX T VO  NOOE 
" »E  BEGTN  ~ 

K : = VAR  OCL  TREECK 3. FIRST  SON ! 


ELS 


WHILE  (VAR  tJCL  IREtTK  3.  TOONiER.HROTHC’it 
r:sVAR~OCL  IREEK  3.TOUN3E1'  ‘HOTHCR  ; 
VAR  OCL  TREECR3.T0LNGER  HROThEA:= 

— HrvT*un  Mnnr! 


A 3)  00 


ENOI 

eno; 


eno; 


next;vo_nooe; 


BEGIN 

WITH  VAR  OCL  TREECNEXT  V3.NCOE3  00 
BEGIN  " 


PTR  TO  VO  TABLE  t sNEX  T VD  ROW! 
31201=0; 


then  fathfr:so 


PR  NAWFISPROC  narf; 
first  son:*o;- 
rouN'.ro  h»other:io; 

IF  PHOC-NARt  = tOUT_ROST  • 

CL-.E  ^ARF  i s T T ACKC  TOP  O'  3 T AC K- ? 1 . ! 

1 1 rMAjn (F  A THf  1 NA«E)J  ~ ~ 

PT.tStn; 

WHILETF-ITHFR  NARt  * HASH  TA0LFCJ3.PR  NAR.TOO 
BEGIN 

RFMEAf  t;s(I»i»  too  hash  “U;  LENGTH! 
UNTIL  THAiH  FI.T3C11  * JT! 


•■m}.  ,y« 
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JIxMASH  PTRSC I 31 

eno; 

JJsHASH  TAHLEE J].PTR  TO  PKOC  T'TE; 

fa  iHt.<:?Pnoc  *.i  ireeT j j^ptr  to  vonooe; 

ENOS  “ “ “ 

end; 

FILLUP  SON  BROTHER; 

NEXT  VD  NODE : = NE  X T VO  NOOE*lI 
L NO  « “ 

PROCEDURE  FILLUP  VO  TABLCI 

var  i . 1 1 . jj: integer ; 

PROCEO'JRE  INSCRI  INTO  VJTAOS 
BEGIN 

CASE  ASFR  OF 
1:  BEGIN 

(•  SIMPLE  VAR  •» 

WITH  VAR  OCL  TARLECNEXT  VO  ROW)  00 

regin  vntine:5Io;  inoic:?asfr;  tcooe:=ott; 
eno; 

save  simpleittp;; 
eno; 

2«s:  begin 

(•  SIMPLE  STRUCTURE  VAR,  NOT  •> 

!•  ARRAY  OF  RECOKOS.  •» 

WITH  VAR  OCL  TAILTNEXT  VO  ROW)  CO 

BEGIN  vn*ne:*io;  incic:*asfr;  tcode  ;=s  tr  r ; 
eno; 
eno; 
s:  BEGIN 

!•  SIMPLE  VAR, STRUCTURE  TYPE.  PREOCL.  • ) 
WITH  VAR  OCL  TABLECNEXI  VO  ROW]  00 

begin  vnahet=id;  inoict=asfr;  tcooe:=ii; 
eno; 
eno; 

a:  begin 

<•  ARR A YC ... ]0F  REC.REC  PREOCL.  »> 


WITH 

BEGIN 


eno; 


ENO 


eno; 


AR  OCL  TXHLtCNEXT  VO  ROW]  00 

vn*me:5io;  inqic:;asfr;  tcooe: 
ttcooeisstt; 

HANDLE  AR  ST  FLI 

save  sTmpcecTp  name;; 


-i  i ; 


NEXT  VO  ROUJsNEXT  VO  ROW*H 
VAR  OCL  TREE!  NEXT“VO~NOOE-l 
VAK-OCL_TR£ECNEXr-VO*NOOE-l 


ENO 

(•  MAIN  BOOT  OF  FILLUP  VO  TAB 
BEGIN  - 


») 


code:=o;  get  token; 

REPEAT 

IF  ( ST-*  SET  * I OR  IFL=*FILEM  OP 
< RC= • PACKED • ) OR  <!YPCIJ=*!‘> 

THEN  BEGIN 

hanole  ar  st  fl;  asfr:=i; 

INSERT~INT 0 VCTAB  t 

ENO 

ELSE  IF  ARs  • ARRAY  * THEN 
BEGIN 

SIMPLE  OR  RECORO(II.JJ); 

CASE  3j  OF 
i:  BEGIN 

asfr:=j;  inslrt  into  votah; 
lev:=i;  rsui;” 
handle  recoroiio;; 

VAR  0CC  TAHLECNEXT  VO  ROW-1 ]. TTCOOY : sSTT 

tipe:=tt;  ~ ~ 

hanole  ar  st  fl; 
save  stmpceiTp  name;; 
eno;  _ . 

2:  BEGIN 

asfr:=a;  insert  into  votaq; 
end; 

3:  BEGIN 

asfr:=i;  handle  ar  st  fl; 

INSERT  INTO  VOIAB;  “ “ 

ENO 

eno; 

END 

ELSE  IF  RC= • RECORO • THEN 
BEGIN 

ASFK:s2!  INSERT  INTO  VOTABI 

lev:=i;  rs:si; 
hanole  recoroiio;; 

ENO 

ELSE  BEGIN 

SIMPLE  OR  RECORD! 1 1, JU> I 
IF  JUS?  THEN 

BEGIN  ASF-Csb;  INSERT  I NT  i VO  I Ail; 

ENO  ELSE 

asfr:sl;  insert  into  votau; 


BEGIN 

eno; 
end; 

gft  token; 

UNTIL  NOMMORE  VARi; 
eno; 

PROCEDURE  TTPE  PROCESSOR; 
VAR  1 1 ,jj: INTEGER S 
BEGIN 


UHIS  PASS  IS  BEST  QUALITY  FRA 
IRON  CSQP.Y  FWLSHBC  JODfifl  •' 
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jtpsw:-:i;  coorzsss  get  token; 
repeat 

coor:*v;  get  token; 

IF  C CKC=*PACKlU' > D.(  CSTHSEM)  OR 
CFLs*FILt»)  OR  (TfPC !)£•<•)» 

THEN  SAVE  SIMPLFCIO) 

ELSE  IF  AR=*AKHAY*  T HtN 
BEGIN 

SIMPLE  OR  RECOROCU.JJ); 
ca or  3j  "OF 
i:  BEGIN 

WITH  STRUCTURE  TAriLCCSTrtTJ  00 
BEGIN  LEVELIi?;  NAME!:IO;  INOlJiM*; 
INO’:**R»;  TCODE I - ST  RT. 1 ! 

END  ■ 

strt:=strt*i ; neb  type  nape; 

lewisi;  TSJslI 

hanole  recjrcctp  name;; 

ENOI 

2:  BEGIN 

WITH  STRUCTURE  TAOLECSTRn  00 

begin  level: nT  name:=io; 

inoi:=»a»;  ino2:='R* ; 
rcooetsii; 

end; 

str  r: istrt*i ; 
end; 

j:  save_simplecio> 
end; 

END 

ELSE  IF  RC=*RECORO*  THEN 

begin  lev:=i;  ts:=i;  handle  recordciu>;  end 

„ ELSE  SAVE~SIMPL£C ID>; 

cooe:s3j  get  token; 
unt il( not  bore  vxr>; 
ttpsu:=2; 

ENOI 

«•  MAIN  BOOT  OF  VAR  OCL  PROCESSOR  O 
BEGIN 

CREATE  VO  nooe; 


£Jr 

#/ 


bore~var:=true;  " “ 

COOET=3;  get  token; 

WHILE  I ( MORE  VAR)  ANO  CIO  i'TYPE  •))00  GET  TOKEN? 
IF  IO='TTPE  • THEN  TYPE  PROCESSOR; 

WHILE  < TOKEN=*VAR  " *>00 


IF  POS  NEW  TTPE=-t  THEN  POS  NEW  TYPE  ? = STMT  NO-II 
MORE  JXR:=TR'JE1 
FILLDP  VO  TABLES 
ENOI 

eno; 

PROCEDURE  NL  VAR  PROCESSORS  VAR  N V : I DEN T I FI ER ; VAR  TV :STR [ NG2 ) ; 
FORWARO; 

PROCEDURE  LOOKUP  PROC  NAMES! VAR  PROC  SAME  FOUND : BOOLEAN) i 

var  i.j.k:integer;“ 

C»  CHECK  IF  IDENTIFIER  IS  A PROCECURE  •> 
t*  NAME.  IF  SO. SAVE  IT  IN  NL  VAR  I ABLE  *) 

BEGIN 

PROC  NAME  FOUNO:=FALSE> 
j:=hjshcid>;  i:=ji 
k:=hash  ptrsCjT; 
if  k=o  Then  goto  boo; 

WHILECIO  » HASH  TA8LCC  K 3. PR  NAME)  CO 
BEGIN 

REPEAT  j:=(J»I>  MOO  HASH  PTRS  LENGTH. 

UNTIL  CHASM  PTRSCJJ  * 0*1 

k:=hash  ptrscJJ; 
if  isj  then  goto  500; 
end; 

pvdt:=hasp  tarleck t.ptr  to  froc  tree; 

IDT:  = »PR*;”  NL  VAR  PROCESSORUt.ICT)*. 

cooe:  = t;  get  token;  proc  nams.  fcundutrue; 

500:; 

eno; 

PROCEDURE  CURRENT  “ROCCVAR  LSINTEGER) > 


VAR 

I • j: integer; 

C» 

Give  A POINTER  TO 

PROC/RD  TREE  TO 

THE 

»> 

c • 

CURRENT  PROCEOURF 

WHERE  IDENTIFIER 

IS 

• ) 

c • 

FOUND  IN  ITS  BODY. 

• ) 

BEGIN 

PROC  NAME :=$TACKC TOP  OF  ST  ACK-l  I. NAME i 
• JISHIOHCPHOC  NAME);  ~ 

I PiRsru  i; 

WHILMPROC  NAME  AM  ASH  TAHLECII.PR  NAMF)  DO 
JFGIN 

RLPEAT  j:=CJ*l>  MOC  HASH  PTRS  LENGTH; 
UNTIL  CRASH  PTRSCJI  «0)T 
IIsHAGH  PTHSC3J; 

eno; 

l:=hash  tarlccii.ptr  to  proc  tree; 
end; 

PROCEDURE  OCL  Area  C VAR  L .L0 «H I J IN TE GiR ) ; 
var  i . j: integer; 
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(•  cm  LOWER  AND  HIGHER  POINTERS  TO  • > 

(•  DECLARATION  AREA  OF  PROCEOURE  •» 

(•  POINTED  TO  Of  L . •> 

BEGIN 

J : sPMOC  K:i  TRTCL3.PTR  to  vonooci 
lo:=vah_dcC  tkeecji.ptb  rn  vjiaole; 

H I :*w AR  OCL^f REEC Jj.SI2C»LOI 
END! 

PROCEOURE  SEARCH  WO  TBL ( WAR  L t PT WO TBL : I N TPGER » S 
war  i.  j,k: integer; 

(•  SEARCH  WAR  DCL  TABLE  FOR  I CENT  IF  I ER  • > 

(•  TO  SEC  IF  TO  IS  GLOBAL  OR  LOCAL.  •> 

begin  k:=e; 

REPEAT 

OCL  AR£A(L»J»I)S 
WH ICE  (J<t)  00 
BEGIN 

IF  IO=VAR  OCL  TAHLECJJ.VNAME  THEN  GOTO  6971 
ENO  5 

l:=proc  rb  treecli. fathers 

UNTIL  <L?0»r 

<*  IDENTIFIER  IS  NOT  FOUNO  AT  ALL.  •> 

PTWOTBLIso; 

GOTO  698  * 

697:; 

<•  IF  P TWO TAPER  > IOENTTFIER  IS  LOCAL  •> 

I.  IF  PTWOTAIOG  > IDENTIFIER  IS  GLOBAL  ») 

(•  IF  PTWOTAB50  > IDENTIFIER  NOT  FOUND  • > 

IF  K = L THCN  PIW0TBL:  = -J  CLSl  PTWCTrlL:  = j; 

69«:; 

end; 

PROCEDURE  SEARCH  COMPONENTS  (WAR  J:INTE8ERI  WAR  FO'JNOI BOOLE AN ) ; 
WAR  M ! INTEGER i — 

(•  SEARCH  STRUCTURE  TABLE  TO  SEE  IF  • > 

(•  IDENTIFIER  IS  A COMPONENT  OS  SOME  •) 

(*  STRUCTURE  W AR I ABLE . • > 

BEGIN 

if  j<o  then  begin  j:=j»i;  eno 

ELSE  j:=WAR  OCL  TABLECJ7.rCOOE*i; 

founo:=false;  restructure  tablecj]. level; 

WHILE  (M<= STRUCTURE  T A BL  EC  3 J.LE  VEL  > 00 
BEGIN 

IF  STRUCTURE  TABLEC JB.LEWELsR  THEN 
IF  STRUCTURE  TABLECJ7.NAME-I0  THEN 
BEGIN  FOUNOTsTRUE;  GOTO  8SAI  END! 

eno  t 
85951 
ENO  I 


PROCEOURE  STRUC  WAR  HANDLING! 

WAR  L,PTV0TBC,I.3:iNTEGERI 
FOUND: BOOLEAN  I 

BEGIN 

CURRENT  PROCILU 

SEARCH  70  THL(L,PTW0TBL> ! 

!•  A STROCTURE  WARIAHLE  IS  GLOBAL. SAWE  IT  •» 
(•  IN  THE  WITH  STACK.  • > 

IF  PTWOIHL>0  THEN 

BEGIN  WI IH  STACKC TUS , 17 : =PTWD TBL I 

with~stackctus,25:=o; 

iws:stus*i; 

eno; 

(•  IDENTIFIER  IS  NOT  FOUNO  IN  WAR  OCL  FABLE 
(•  SO  IT  MIGHT  BE  A COMPONENT  CF  TOME- 
(•  STRUCTURE  VARIABLE.  THEREFORE . SE ARCH  THE 
C»  STRUCTURE  TAHLE.IF  IT  WAS  FOUNC  THERE, 

(•  SAWE  IT  IN  WITH  STACK.  THE  SECOND  COLUMN 
(•  OF  WITH  STACK  IS  IN  A SENSE  A KINO  OF 

(•  DYNAMIC  LINK 

IF  PTWOTliLiO  THEN 
BEGIN 

i:=tws-i; 

WHILE  <!>:!>  00 
BEGIN 

j:switp  stackci.m; 

SEARCH  COMPONENTS! J. FOUNO); 

IF  FOUlU  THEN 
BEGIN 

with  sTACKCTgs,n:=-j; 
winsrACKCTws«2J:  = i; 
rws:5Tws*i; 

GOTO  131 : 

ENOS 


FUNCTION  changamle  : hcolfan; 

(•  A VAKIAULL  IS  CHANGADLE  IF:  • > 

( • • » 

(•  1.  iUMFtHlNG  IS  ASSIGNED  T 0 IT  ») 

(»  APPEARS  IN  A READ  STATEMENT  •» 

(•  >.  APPEARS  IN  A CALL  TO  A • > 

(•  PROCEDURE  AS  AN  ARGUMENT . . ) 

BEGIN 

cnor:=«;  err  tokfn; 

CmANOAOLL  : = < ASSIGNED  WAR)  OR  (PHOC  CALL).- 


I 


ENO! 

procedure  r.Lon»L<v»l»  nonlocaliboolcansvar  jj.  i i : n rro-:*>; 

CHECKS  jafTil.R  4 VARIABLE  l>  riU'IJl  OH  NOT.  •> 

first  ar  looking  at  cohponc nts.then  •> 

WAR  OCL  TABLE.  that  IS  10  SAT,  IK  WITH  •) 

si  ate  re7  r is  us*.n,  rat  PRio-afr  is  with  the  • > 

component *i 

ar  I iJtLtP: integer; 

FOUND! BOOLEAN! 

BEGIN 

NONLOCAL liFALSES 
IF  TwS>I  THEN 
BCG  IN 

i : = rus- u 

WHILE!  l>rl  >00 
BCG  IN 

j:  = jith  srACKfi.n; 

SEARCH  COMPONENT ( J.FOUNO) i 

IF  fou7o  then 
BEGIN 

NONLOCAL  I sTRUE i 111=1!  GOTO  1525 

END! 

eno; 

132:  J 

END 

ELSE  BEGIN 

<•  NOT  I NS  IOC  OF  WITH  STATEMENT  •> 

CUHRENT  PROCID! 

SEARCH  70  TBLIL.PM 

if  p>b  Then 

8EGIN 

nonlocal:=yrue!  jj:=p; 

ENO! 

eno; 

END! 

PROCEDURE  CHNG  NL  VAR! 

VAR  II.JJ.lTlNTCGCR! 

nonlocal ; boolean i 

BEGIN 

!•  SAVE  ANr  CHANGABLE  NONLOCAL  VARIABLE  • > 

<*  IN  NL  VAR  TABLE  BY  CALLING  THE  •> 

I*  NL  VAR  PROCESSOR •> 

IF  CHATJGABCE  THEN 
BEGIN 

GLOBAL! NONLOCAL* JJ. II >! 

IF  NONLOCAL  THEN 
BEGIN 

IF  JJ>0  THEN 
BEGIN 

!•  NONLOCAL  SIMPLE  VARIABLE  - > 

pvot:=jj;  iot:  = mo*;  nl  var  processor! io.iot > ; 

ENO ! 

IF  JJ<0  THEN 
BEGIN 

!•  NONLOCAL  STRUCTURE  VARIABLE  • > 

pvorrs-jj;  iot:=*co';  nl.var_processori io.iot > ; 

while’iwith  STAC«CI,2]«0>  00 
BEGIN 

pvot:=-with  stackci.io;  1 dt : = * co 1 ; 

I0:=»  ~ • I NL  VAR  PROCESSOR !I0. IOT) ! 

i:=with  stackci.z:;- 

ENOi 

PV0TI24I TH  ST ACKC I . I 1 i I0T:=»IO* i 
NL  VAR  PR OCESSOR IlO.IOIl! 

ENO! 

ENOi 

ENO! 

eno; 

PROCEDURE  NL  VAR  PROCESSOR! 

save  The  Uonlocal  changable  variable. 

IF  INDICATORS  *10*  >5IMPLE  VAR 

IF  INDICATOR  = ,RM' >RECOV£R  T BLOCK 

‘ >PP0CC0URE 

>C0MP0NENT 


L 


IF  INDICATORS* Pot 
IF  IN  Dl  C ATOR=  *CD  * 

r v . up | c • 

"P.X.T  IS  STOREO  AS: 

•CO*. > TO  ! V ) IN  STRUCTURE  TABLE 

•CO*, > TO  i X ) IN  STRUCTURE  TABLE 

*10*. >T0  !P>  IN  V AR_0CL_  TABLE 

R CPC  4 T l T [ ON  IS  taken  care  of 

VAR  I, j.m: INTEGER  i 
flagihoolean; 

HEGIN 

PHOC  NAME IsSTACKr TOP  OF  STtCK-1  3.NAME! 

TF  P<T0C  'J4'*£r*0UT  MOlT*~TKEN  G010  551! 
bishashTp  !0C  NAMFT! 
i : smash  pirstm  i; 

KMILC  !?KJC  NAMC  X HASH  TAHLECM.PR  NAME)  00 
BEGIN  " 

RfP'-AT  m::(M*|)  XOI)  HASH  PTRS  LENGTH! 
UNTIL  I BASH  PTRSCHI  » OTi 
i:ihash  ptrscmt; 

END  i 
«::ll 
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MSSMASH  IABLrCM  3.PTR  TO  PROC  TRtCS 

if  pruC  >ut  ri<r..c«l.PiR'ro  nCvaki.;  then 
P.IOC  R'l  Tm  ecmj.ptr  To  Olvahssucxt  nl  VARS 
IF  T5=*C0*  THEM  OGIO  '/if,  ~ ~ 

JI=PHOC  k H T L C M ).N0  NL  V Art  LSEOS 
i:-PMOC  Bn  TREECM3.PTR  To  NLVJHS  j:?j»i; 
yH  ile ( i^j)-oo  “ 

HCGIN 

IF  1 = 1 THEN  Ft_  AG  I - TRUE 

ELSE  FLAGSslNL  VAR  T AHL  EC  I - 1 1.  IN  D l C A T OH  » • CO*  » 5 
IF  (NL  WAR  TAIlCECIT.PTR  TO  « ■)  T A'JrPVOT  I AMO 
(NL  VAH~TAHLEC U. IN0ICATCR=TV > ANO 

fl*g  Then  goio  nsi 
ELSE  i:si*is 

ENOS 

5A9: ; 

ML  VAR  TABLECNEXT  NL  V AR  ).  I NO  I CA  T CR  S = T V S 
NL”vAR"r AtiLtC nex r~NL_vAR j.p n io  vctab:=pvot; 
phOc  RT  r KEEM3.no  nCVAH  USrOT:  ~ 

PROC-RB-rREEC  Ml.f4C-NLVAR-USE0*  IS 
NEXr"NL~VAR:=NExr  «JL  VAR*1  • 

551 :T  - - 

ENOS 

PROCEDURE  BACKTRACK  NLVARS 

(•  NONLOCAL  VARIABLE  AREA  OF  NESTEO  •» 

{•  PROCEOUKES  IN  NL  VAR  TABLE  ARE  •> 

(•  NESTEO  AS  WELL.  “ •) 

(•  BY  CALLING  THIS  PROCEDURE  ANO  •) 

(•  USING  A BACKTRACKING  STRATEGY  •) 

(•  NL  VAR  TABLE  WILL  BE  REARRANGED  •» 

(•  AND  THE  POINTERS  WILL  BE  MODIFIED  •> 

(•  IN  PROC/RB  TREE •> 

VAR  I.LO.Hl.MSINTEGERS 
BEGIN 

CURRENT  PR0C(M>5 

LO:=PROC  RH  TBEEMT.PTR  TO  NLVARS 
H 1 1 =PROC~ RB— f REECN  l.NO  JlLVKR  USE0M.0-1S 
IF  L0»0~  THEN 
BEGIN 

PROC  RB  TREED  M 3.PTR  TO  NLVAR  S=NEXT  NL S 
FOR  T:=CO  TO  HI  DO  “ ~ 

BEGIN 

NL  BUFERt  NEXT  NL 3. I NO IC A TOHJs 
NL"VAR  TABLEtT!). INDICATORS 
NL  BUFERC  NE X T NL3.PTR  TO  VUTA8:= 


NL~VAR  T A BLEC  T 3 • P TR  TV  VDTABS 
NEXT  NC;  = NEXT  NL*1S 


end; 

NEXT  NL  VARISLOS 
end;  ~ “ 
end; 


PROCEDURE  WITH  BLOCK  PROCESSORS  FORWARDS 
PROCEDURE  REC_BLOC<_PROCESSORS  FORWARDS 


BOOT  PROCESSOR 

BOOT  PROCESSOR  GOES  THRU  THE  BOOT  OF  THE 
HI T TED  PROCEOURE.  IT  WILL  LOOK  FOR  THOSE 
VARIABLES  NONLOCAL  TO  THE  PROCEOURE  ANO 
CHANGAHLE  AS  WELL.  IF  THERE  ARE  SLCH  VARS 
THEY  WILL  BE  SAVED  IN  NL  VAR  TABLE. 

IF  THERE  ARE  SOME  PROCEODRE  CALLS  IN  THE 
PROCEOURE  HOOT, THEY  WILL  B*  SAVED  IN  THE 
SANE  TABLE  TOO.  ANOTHER  WORDS.  ANT  CALLED 
PROCEDURE  NAY  CHANGE  SOME  OK  THE  NONLOCAL 
VARIABLES  AS  WELL. 

THIS  PROCEOURE  IS  RECURSIVELY  CALLED  IN 
CASE  OF  NESTED  BLOCKS. 

BY  SEFING  RECOVERY  BLOCKS  OR  WITH 
STAEMtNTS  .CORRESPONDING  PROCEDURES  WILL 
BE  CALLED.  THESE  PROCEDURES  MAT  CALL  THE 
BOOT  PROCESSOR  IF  A NEW  BLOCK  HAS  STARTEO. 
CASE  STAEMtNTS  ARE  TREATEO  AS  BLOCKS 


PROCEDURE  BODY  PROCESSORS 

VAR  PROC  NAPE  FOUNDS  BOOLE  AN S & 

K WS INTEGER  S jjTA 

BEGIN 

C00ES=3S  GET  TOKENS  .TT 

while  (token  a teno  *i  00 

BEGIN 

IF  TOKEN=*BEGIN  • THEN  V 

BEGIN 

BOOT  PROCESSORS  GOTO  301 S 
ENOS 

IF  TOKENS'  ENSURE  » THEN 

BEGIN 

inoic:=c;  lnk:-=i; 

RED  HLOCK  PROCESSOR;  PC“  STACKS  GOTO  JOGS 
ENOS  “ 

IF  TOKEN-* W l TH  • THEN 

BEGIN  WITH  BLOCK  PROCESSORS  GOTO  311 S ENDS 

if  rn*rN=*CAif  ~ • ihen 

begin  Blur  processor:  r.oro  m:  end; 

IF  001  THEN- 


#4 

J/ 


S' 


“7 


BEGIN 

( • 

( • 
( • 


WHEN  DOT  IS  THE  VAlUe  Tf-UE,  THEN  •) 

STRUcrunt  variable  has  ihi  form:  o 

x xx. xx x x >i 


wc:=os 

WHILE  00 r 00 

begin  oot:=falscs 

Stltoc  VAR  HANDLINGS 
wc:=wC»is"  coor.:sji  get  toklni 

ENOS 

CHNG  NL  VARS 
rws:?rws-wcs  goto  jioii 
ENOS 

CHNG  NL  VARS 

IF  NCf<  :hANGABLE  ) THEN 

LOOKUP  PROC  NAP C SC PROC  NAME  FOUND); 

300 : ; - * 

cooe:=3s  get  tokens 

30i:s 

ENOS 

cooe:=3s  get  tokens 

ENOS 


REC_BLOCK_PROCESSOK 

RECOVERT  BLOCK  IS  CALLEO  UHENEVF.R 
AN  'ENSURE'  STAEHEN T MAS  BEEN  SEEN 
IN  THE  HOOT  OF  A PROCEDURE. 

ANT  RECOVCRT  BLOCK  WILL  BE  TREATED 
AS  IF  IT  WERE  A PROCEDURE.  A NAME 
WILL  RE  CREATED  AND  ASS  I GNEO  TO 
THAT, A NODE  IN  PR0C/RB  TREE  WILL 
HE  INSEATEO  WITH  ALL  INFORMATION 
ABOUT  THE  RECOVERT  BLOCK. 

IN  THE  CASE  OF  NESTED  RE  COVERT 
BLOCKS.  THE  PROCESSOR  IS  CALLEO 
RECURSIVELY.  THE  REST  OF  IT  IS 
SIMILAR  TO  BOOT  PROCESSOR 


PROCEOURE  REC  ULOCT  PROCESSORI 
VAR  PNOC  NBME  FOONDT BOOLEAN  I 
I (U:TN  TEGER  S 


PROCEOURE  CREATE  RB  NAMES 
<•  NEW  NAMES  FUR  RECOVERY  BLOCKS 
(•  ARE  CONSIDERED  TO  BE  LIKE: 


(•  ARE  CONSIDERED  TO  BE  LIKE: 

(•  RB000001,RH000002,RH 000003..., 

(•  THEY  WILL  BC  CREATED  WHENEVER 

(•  A RECOVERY  BLOCK  IS  SEEN 

VAR  I : INTEGER S 
BEGIN 

t:=ORO(RS  NAMECIO  LENGTH!) S 


IF  1=57  THEN 
BEGIN 

Rd  NAMECIO  LENGTHJ:='0»S 

RB"NAMEC  ID~LENGTH-n:  = CHRCSUCCCOROCRB  N AMEC  I D_LENG  TH- IT  > ) ) S 
END" 

ELSE  RB  NAMECID  LENGTH 3 :=CHR ( SUCCC ORO C RB  NAMECIO  LENGTH  3 ) » I S 
ENOS  " - . 

C*  MAIN  BOOT  OF  REC  BLOCK  PROCESSOR  • ) 

BEGIN 

CREATE  RB  NAMES  IOT:='RB'S 

pvot:=fiexT  proc  nodes 

NL  VAR  PROCESSOR ( R B NAME . I 0 I ) S 

proc  nZme:=rh  names"  prb:=*rb's 
CREATE  PROC  NODES 
“USH  STACKS" 

INSERT  HASH  TABLES 
C00f:=J;  " GET  TOKENS 

WHILE  (TOKEN  » 'ELSE  ERROR  •>  00 

BEGIN 

IF  TOR ENs 'BEGIN  • THEN 

BEGIN 

BOOT  PROCESSORS  GOTO  801S 
ENDS 

IF  TOKENS 'ENSURE  • THEN 

BEGIN 

inoic:=?s  lnk:=is 

REC  BLOCK  PROCESSORS  PC?  STACKS  GOTO  BOOS 
END;  “ 

I F ( TOKENS • BY  •)  OR 

( TOK ENS • ELSE  BY  •>  THEN 

BEGIN 

inoic:s2S  lnk:=is  goto  aoos 
end; 

IF  TOKENS'WITH  • THEN 

RIGIN  WITH  BLOCK  PROCESSORS  GOTO  HOIS  ENDS 
TF  TOKENs'CISE  “ • THEN 

BEG  S U BOOT  PROCESSORS  GOTO  801S  ENDS 
IF  DOT  THEN 
BEGIN 

wr:  = os 

while  (ooti  no 

HEGIN  OOCsFALSF.S 

STRUC  VAR  HANDLINGS 

^ wc : =wC. i s " cu,)k:  = js  gft  token; 

ENOS 

CHNG  NL  VARS 

rws:;rwS-wcs  Goto  too; 

ENDS 

CHNG  NL  VARS 

IM  NOT (O'ANGAHLE ) THEN 


lookup  pane  namesiproc  name  founoi; 
rub:; 

COOL : = Jl  GE  T TOKEN ! 

H01JS 

LNO. 

BACKTRACK  NLVAR; 

IN0IC:=2I  LNKJiJJ 


y I rh_Qi.  OCK_PROCCSSOR 

ALL  ITS  ACTIONS  A At  EMCTLT 
SAMf.  AS  THOSE  OF  HOOT 
PROCESSOR  AND  RFC  BLOCK 
PROCESSOR.  THIS  PROCESSOR  IS 
DESIGNED  TO  TAKE  CARE  OF  ALL 
POSSIBLE  FORMS  OF  WITH  STMTS. 
ekample: 

WITH  XX.XXX....  00 
OtGlN 

WITH  XtXXXXt...  DO 
WITH  XXXXX  00 


all  these  names  x.xx ,xxx. .... 
KILL  BE  STOKEO  IN  WITH  STACK 
AS  THET  APPEAR.  AND  MILL  BE 
POPEO  OFF  STACK  AS  THE  BLOCK 
IS  ENOCD 


PROCEOURE  «ITH  BLOCK  PROCESSOR! 

VAR  PROC  NAME  FOJNOIOOOLEAN! 

L ASI“ TyS.PTVOraL.L, I. j: INTEGER! 

FOUND : BOOLE AN ! 

BEGIN 

last  tus:-tus; 

9ao:T 

C00t:=3!  GET  TOKEN! 

WHILE  < TOKEN  1 *00  •»  00 

BEGIN 

STRUC  VAR  HANDLING!  COOET^J!  GET_TOKEN! 

ENOi 


cooe:=u  get  token; 

IF  TOKENS  ’WITH 
IF  T OKEN - • BEGIN 


BEGIN  HOOT  PROCESSOR;  GOTO  9A«!  EN0J 


• THEN  GOTO  9A0! 

• THEN 


IF  TOKEN-'CASE 


• THEN 


BEGIN  BOOT  PROCESSOR!  GOTO  9M ! ENOI 
IF  TOKENz’ENSURE  • THEN 

BEGIN 

IN0IC:i2!  LNKIsli 

REC  BLOCK  PROCESSOR!  POP  STACK! 


CNO I 
REPCAT 

IF  T OKEN=*  BEGIN  • THEN 

BEGIN  BOOT  PROCESSOR!  GOTO  9»ii  ENO! 

IF  TOKEN='E!ISURE  • THEN 

BEGIN 

inoic:=2!  lnk:=i; 

REC  BLOCK  PROCESSOR!  POP  STACK! 

ENOi 

IF  TOKEN=’WITH  • THEN  UITH  BLOCK  “ROCESSO’! 

CHNG  NL  VAR! 

IF  NBTTCHANGABLE ) THEN  LOOKUP  FROC  NAMESTPROC  NAME  FOUND  I ! 
C00E:=3!  GET  TOKEN!  “ " 

99i:i 

UNTILTSEMI  COLON) OR ( PREV  TOKEN: ' ENO  •)! 

bra:; 

tvs: =L AST  TUS! 

ENO! 

PROCEOURE  FILL  ENO  OCL  PTRi 

(•  PROCEDURES  ARE  ALWAYS  OECLAREO  IN  •) 

(•  DECLARATION  AREA  OF  OTHER  • ) 

(•  PROCEDURES.  THE  ENO  OF  DECLARATION  *) 

<•  OF  ANT  PROCEOURE  THEREFORE  IS  THE  •) 

«•  LAST  DECLARATION  BEFORE  ITS  MAIN  •) 

<•  BLOCK.  THIS  POINT  MUST  BE  SAVED  •) 

(•  IN  PROC/RR  T RE r FOR  EACH  PAOCtOURE  •) 

(•  TO  BE  USED  L Af r R ON.  WHEN  A •) 

(•  RECOVER T M..OCK  HAS  BEEN  TRaNSLATEO  •)  , 

(•  TO  A PROCEDURE.  IT  MUST  BE  INSERTED*  > A - 

<•  AT  THE  ENO  OF  DECLARATION  OF  ITS  »)  £>',£»• 

(•  FATHER’S  O'.  CLARA  T I ON  AREA »)  V & 

var  t,j: integer;  -T* 

BCGIN 

PROC  NAmE::STACKCPREO(TOP  OF  STACK) 3. NAME! 

J:sMISH(PROC  NAME)!  ~ " A,  /sr 

IIIHASH  ptrsTj  I!  & Pv 

WHILE!  PSOC  NAME  » HASH  TADLEC  I 3.  PR  NAME)  00  §?  & 

BEGIN  g*  S? 

RCPEAT  j:=(j»l)  MOO  HASH  PTRS  LENGTH!  & V 

UNTIL  (HASH  PTRSCJJ  f Ol t ~ 4T 

l l SHASH  PVRSCJT.  .GFV 

JISMASm  T AOLEC  J ) .1’  T R TO  “ROC  TREE!  & 
PROC_Rf»_TRtF:ru  ),PTR_ro_rNO_OClT=LlNE_NO!  S'  £ 


/ 


MAIN  BOOT  OF  PROC_OCL_PROCES  iOR . 


V 


.i\  ■ 


• IHEN 


BEGIN 

IF  FIRST  CALL  THEN 
BEGIN 

coor:=is  get  t OKt  ni 

end; 

create  proc  nooes 

INJERT_MASH  TABLE! 

push  stack;" 

VAR  CCL  processor; 

UHICEI  TTOKEN='PKOC£DURF  •>  OR 

CTOKENs'FUNCTlON  •))  00 

BEGIN 

prh:a'PR'! 

COOEISA;  GET  TOKEN! 

LAST  PROC:=P"OC  NAME! 

PPOC~UCL  PROCESSOR! 

ENO! 

FILL  £ND_UCL  PTRI  . 

IF  TOKEN  * 'BEGIN  • IHEN 

HECURITELN( '••••  ERROR  AT  STMT  NO . • , S TM T NO  : A > ! 

JRITELNI • •••*  BEGIN  EXPECTED*  BUT  ENCOUNTEREJ  ' , TQKc.N ) S 
ENO ; 

cjol:=2!  iNtiic:  = a!  lnk:=a;  get_ioken; 

IN01C:=1!  T«s:sl! 
hoot  processor; 

BACKTRACK  NLVARi 
POP  stackT 
root; 
end; 

PROCEDURE  COPY  BACK! 

var  i:integer; 

BEGIN 

BEGIN:NL  VARNMBCEbn.INOICATOR:=NL_BUFERCI  VINDICATOR! 
NL  VAR'TABCEC II.PTR  TO  VOTAHts 
NL~BUFERC I VP  TR_TO_VO  TXH! 
eno;~ 

NEXT  NL  VAR:=NEXT_NL! 

ENO! 


MAIN  BOOT  OF  PASS_1 


INITIALIZE  PASS!! 
PROC  CCL  PROCESSOR! 

copt"bacR; 

PRINT  RESULT! 


PROCEOURE  SAVE  LINE! VAR  FILEN: TEXT  FILE! VAR  BUFER  I TEXT  LINE! 

VAR  LINE  NO! INTEGER)! 

forward; 

PROCEOURE  READ  LINE! VAR  FILENJTEXT  FILEiVAR  BUFFERtTEXT  LINE! 

VAR  LINE  NO: INTEGER) ! 

var  i : integer; 

BEGIN  l:=l! 

WHILE  (NOT  EOLN(FILEN) ) 00 

BEGIN  KEAOtFILEN.BUFFERCni;  I!=I*1!  ENO! 

RE AOLN (F ILEN ) ; 

FOR  J:=I  TO  LINE  LENGTH  00  BUFFEfiCJ]:=*  • ; 

LINE  NO:=LINE  N0*1!  TXT  PTRIsli 

ENO! 

PROCEOURE  SAVE  LINE! 

BEGIN  WRITECNIFILEN, BUFER)  ! 

LINE  NO:=LINE  NO*l!  C0LJ=15 

WMILEUHUFERCCOL  V » ) AND(  COL  <L  I NE  LENGTH)  ) 00  C0L:=COL*i; 
IF  C0L=LINE  LENGTH  THEN  COL:=II  . 

ENO! 


PASS  TWO 

PASS  2 GOES  THRU  THE  INPUT  PROGRAM  ONCE  MORE  ANO 

USING  THE  CONTENTS  OF  SEVERAL  TABLES  GENERATED  B 1 

PASS  l.WILL  00  THE  FOLLOWING! 

1.  ANT  FIRST  LEVEL  RECOVERT  BLOCK  JILL  ME  TRANS 
LATEO  INTO  A PROCEDURE  ANO  COPIED  INTO  A FILE 
CALLED  INCREMENT  TEXT. 

2.  I ME  RECO/ERY  BLOCK  IN  THE  ORIGINAL  TEXT  JILL 
HE  IGNOKcO  ANO  REPLACEO  MY  A CALL  TO  JUST 
TRANSLATED  RECOVERT  BLOCK. 

3.  THE  FIRST  TWO  STEPS  WILL  HE  PERC0RM.E3  FOR  ALL 
FIRST  LEVEL  RECOVERT  BLOCKS  IN  THE  TEXT  INPUT 
FROM  PASS  1. 

A.  IF  THERE  APE  NESTED  R EC .BLOCK S ,PA SS  ? WILL  ME 
CALI  F C AGAIN  THIS  TIME  ITS  v<3LMrKT  IS  TH  E 
INCREMENT  TEXT, THE  OUTPUT  F-MM  'ASS  ITSELF. 

M.  PASS  2 JILL  HE  CALLtJ  AS  LONS  AS  (H^Rr  ARE 
MORE  LEViLS  OF  PFCOV'RY  BLOCKS. 

ft . AT  the  VLRT  rrvo.ALL  THESE  TEXTS  JILL  ME  MERGE J 
TOGt  IHER  AN)  THAT'S  .HAT  CAN  Jt  ACC'PTCO  HY 
A REGULAR  PASCAL  COMIMLFR. 

IN  GENERAL  PASS  » HAS  THE  FOLLOJINv  FORM! 

FROM  PASS  1 
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I 


I 


| PASS_2  | 


INCRERENI_TEXT1 


j PAS3_2  I 


INCREMENT  TEXT2 


TEXT1.TEXT2....AN0  THE  LAST  INCREMENT  TEXT  TO  BE 
MERGEO. 


PROCEDURE  PASS  2(VAR  TEX T l * TE XT2 . TEXT J : TEX T FILE  ) t 
y/ ar  ” ~ 

i .j.k.n: integers 
buf, lastline: text  line; 
no oe.nodeptr, search  direction: i a teger; 

QLOPTKIINTEGER; 

ELDER  BROTHER  « ELD  PTR: INTEGER! 

PRO : STR I nob; 

RB  TO  PROCIARRAYC I..NO  OF  PROC J OF  INTEGER! 

PROCEDORE~Pur  LI'IEIVAR  FILCNiTEXT  FILE;  VAR  8UFER : TEXT  LINE! 

var  line  no:integer>; 

var  i:integer; 

(•  A GENERAL  PROCEDURE  TO  WRITE  A TEXT  LINE  •» 

(•  ON  A FILE* •COL*  IS  A VARIABLE  POINTING  TO  •) 

I * THE  STARTING  OF  EACH  LINE  JUST  WRITTEN  ON  ») 

(•  ON  FILE.  IT  IS  USEO  FOR  THE  PURPOSE  OF  •> 

<•  INDENTATION. •) 

BEGIN  WRITELN(FILEN.9UFER>  I 

LINE  NOISLINE  NO*l!  i:n; 

WHILEHBUFERCT3=»  •>  AND  CKLINE_LENGTH)>  00 
i:  = I*l!  IF  I<  LINE_L£.NGTH-l  THEN  COLIsI! 

ENO  J 

PROCEDURE  GET_LI VE  < VAR  FILENJTCXT  FILE?  VAR  BUFFER: TEXT  LINES 

var  i.jiinteger;  V4R  <-Ine.no:int-Cep, ; 

BLANK. CONENT: BOOLE AN ; 

J • A GENERAL  PROCEDURE  TO  READ  A TEXT  LINE  «l 
i • FROM  A FILE.  COMMENTS  ANC  BLANK  LINES  *) 

<•  WILL  BE  TAKEN  CARE  HERE > 

BEGIN  i:=i; 

WHILEINOT  eolncfilenmoo 

«8^^^{e^uEN•8UFFEficn,5  i:=m;  eno; 

FOR  j:=l  TO  CINE  LENGTH  DO  RUFFERCJ3:='  •; 

LINE  NO:=LINE  N3?i;  TXT  FTRI=i; 

IF  IHDIC=1  THEN  GOTO  771!" 

blank:=true;  comentisfalse; 

FOR  J:=X  TO  LINE  LtNGTH-l  CO 
BEGIN  IF  8UFF  ERCtJ  I#  * • THEN 
BEGIN  HLANK  IiFALSC; 

IFUBUFFEHt  JJr*(*>  AND 

»HUFFCRIJ.13s».-*>>  THEN 
BEGIN  COMENTrsTRUE!  GOTO  T 70 1 ENO 
ELSE  GOTO  T71I 

ENOI 

eno; 

7 to:; 

IF  (BLANK  OR  CONENT  T THEN 

BEGIN  IF  INDIC=2  THEN  PUT  L I ME < TEXT2 , BUFFER ♦ PTR? > 

ELSE  °IJT~L  INE  ( TEX  T 3 .BUFFER  . PTR  J ) ; 

GET  LINE(FILEN, BUFFER. LINE  N0»; 

eno; 
t t i : ; 

eno; 

PROCEDURE  FCOPTIVAR  TE  X T 1 , TE  X T3 : TE  X I FILE!  VAR  RUFITCXT  LtN*-; 

"var  ptri.ptr  i.n: integer* ; 

BEGIN 

(•  COPT  A PORTION  OF  ANT  FILE  • » 

(*  INTO  ANT  OTMFR  FILE.  «» 

WHILE  iptrkni  00 

BEGIN  lNDIC:=t;  GET  L t N£  ( Tf  X 1 1 ,B'JF  *PTR  I J • 

PUT  L I NE ( T EX  I J7RUF  , F I R 2 ) I 

ENOS 

LNU!  ' . 

PROCCOURC  FILL  ADR  FICLD(VAK  IIUFERIIEXT  LINEJVAR  J,  K : ( N(  l <,-L  V* 
forward;  ~ j, 

PHOCt.DURE  G‘  NCR  A TE  C ALL  (VAR  OUEITExT  LINE  I V A R JIINTELL  ); 
forward;  “ - % * 

procedure  create  linkage;  

105  JBIS  PACT  IS  BEST  QUAiin  mCTICABU 

JHOM  OQPY  FyPKiSK®  3»DftC  


c* 

CREATE.  A »tLlNKAGf 

AOR  • 

staefcnt 

.WHERE 

M 

}» 

AOR  POINTS  T.)  r N C K L 

ME  NT 

TEXT.  IT 

WILL 

• ) 

(* 

USED  IN  MERGING  THE 

It  X 1 

IS 

O 

BEGIN 

K JiPROC  MS  TREECNODrPTR ). FATHER; 

NI^M  »OC”'Ct  TREECK  J.PTR  M LNO  OCL-i; 
FILL  A07  FTflDILASTLINE.JTM I 
PROC  R II  TRr.MK  l.l'IR  IS  -NS  flCi:=PTR21 
litMfTArr  CALL  (HUFER7NO0EMTH)  i 

put  LiNFrrExnf»UFtR,prin)  j 


FUNCTION  YOUNCEMVAR  NOOF  P TR  : I N TEG  Eftl : 6 COLE  AN  ? 

var  i:  in  rest  r; 

<•  this  function  rfturns  true  if  •> 

(•  The  PROCEDURE  OR  RCCOVFRT  'ILCK  »» 

(«  POINT E 0 TO  Of  NODEPTR  HAS  ANT  •) 

<•  YOUNGLK  BROTHER.  OTHERWISE  IT  •> 

(•  RETURNS  FALSE *) 

BEGIN 

i:=noofptr;  younger:=falses 

WHILE  <PHOC  «B  IREECI  I. YOUNGER  3RCTHER  «01  00 
BEGIN  " 


ENO 

ENO! 


l:=PROC  RB  TREEC  I 3.  YOL'NGF  R BROTHER; 

IF  PROC  Ra“TREECI 1. INDICATOR  =»RB«  THEN  YOUNGE  R I sTR'JE  I 

ft!  " - 


PROCEDURE  FINO  ELDER  BROTHER} 

var  i, j: integer:  “ 


(•  RETURNS  THE  ELOER  BROTHER  OF  *1 
(•  ThE  RECOVERY  BLOCK  OR  •> 

<•  PROCEDURE  POINTEO  TO  BY  •> 

< * NOOEPTR  if  ANY.  OTHERWISE  «) 

(•  RETURNS  NULL.  (NULLED  *1 

BEGIN 

ELDER  BROTHER:=t! 

i:=prOc  rb  treecnoqfptr j.fathert 

I:sPR0C-RO~TREEC M. FIRST  SCNS 
IF  i=noDeptr  THEN  goto  15o; 

WHILl  (I  FNOOEPT R ) 00 
BEGIN  J::l; 

I : =PROC_RB_ TREEC I 7. YOUNGER  BROTHER  5 

END  I 

IF  PROC  RB  TREECJ7.INDICAT0RS»PR*  THEN 

■ - ELCFR  BRO  THER  I s 1 

ELSE  ELCER_BR0THER:=2; 


PROCEDURE  CONVERT_OECI M AL I V AR  BUFER: TE XT_L I NE i 


var  m:integer; 

(•  A PORTION 


VAR  I. J.k: INTEGER) ; 


A PORTION  OF  THE  TEXT  LINE  IN  BL'FER 
STARTING  FROM  J TH  POSITION  AND 
ENDING  AT  I TH  POSITION  IS  CONVERTED 
TO  A DECIMAL  NUMBER. 

STRING  ======£==>  NUMBER 

N 

g • -Q  ' | • 

REPEAT  K : = KMORO(BUFERCJ3)-48)  *MJ 

m:=m«io; 

until  (J<(>; 


PROCEOURE  FILL  AOR.FIELOI 
var  m,i,l:in7egeK; 

C«  A NUMBER  < WILL  BE  CONVERTEC  TO  A .1 
I*  STRING  AND  WILL  BE  CO^IEO  INIO  THC  •> 
(•  TEXT  LINE  LOCATED  AT  BUFER  STARTING  *> 
(•  FROM  J TH  POSITION.  •) 

<•  NUMBER  •*•■»-■«)  STRING  •» 

BEGIN 

m:=iooo;  l:=k; 

repeat  l:sK  OIV  m;  K:sK-I.M5 

BUFERC  J3:  = CHR(0  (DU  )♦<«)  ; 
m:=m  oiv  1 o ; 

UNTIL  <N=0)S 

k : -l  ; 


PROCEOURE  GENERATE  CALL} 
VAR  NAME: IDENTIFIER} 

t:  integer; 


l»  Gf  NrR  ATr  A CALL  TO  THE  GENERATED  •) 

(•  PROCEDURE  CORRESPONDING  TO  THE  •) 

<•  RECOVERY  BLOCK •) 

NA“L:iPM’)C  RH  TRLEt.IJ.PR  Rb  NA“E  i 

FOR  t:  = i TO  Mne  LENGTH  DO  RuFCI):i«  *5 

for  i ;= i to  ;p  l'n&th  no  rlfcc3l»i-i  3:=nam«tc  1 1: 

I F < ( NO  T REMfCOCON)  AND  <L  E t -L  AS  TCL  St  »ROR  > > 

THcN  SL'MCOLJNI-f.RUE  ELSE  BLF  C COL  * I - I J J = • i • ! 


PROCEDURE  OCL  FAULTFLAG; 

V A K I . J : I N f CGr  * i 
NAMT :STM|NG?0: 

(.  GrN|RA'L  » J'CLAFATION  STAEMfjT  FOR  •) 
C . IIUuL1  *'•  VVRlAHlE  CALLIO  'YAULfFLAG*  •! 
(•  AT  THL  END  Of  UCCIARAUON  ARIA  CF  .» 

(•  the  main  


d 


i 

j 

i 

\ 

. 

J 


BEGIN 

jt sPPOC_R ! 

Ihe 


son; 

•PR  * 


PROC  R)  TRCECNOOCPTR J.FIRSI 
proc  H'i  rpri  c i j. indicator  up 
N IT:p70C  ft  H T* ICC  I J.tVl  I ft  Y 
LL  ItsPNOC  ft'l  TrLCC  NOOF;*YR  I.PIR  TO  ENO  OCL^U 
FCOPY!  TEXT  l .TLxTJ.HUFFR.PTK 1 ,PIP J7l  >T 


i:=col ; 

FOR  j:n  TO  LINE  LENGTH  00  HLFERCJ15S*  •! 

NAME  I s * FAUL  tflagthooleak;  •; 

FOR  J.’rl  TO  21  00  HUFC RC  l » J-l  ltsNAMEC  J ll 
PUT  LINE! TEX M.BUFER.PTROI ! 

end; 

PROCEDURE  NEW  NODE ! VAR  SEARCH  01 REC 1 1 0 N : IN YE GER) ! 
v ah  j> i : in ieger ; 

!•  TRAVELLING  ON  PROC/RB  TREE  •» 

!•  IE  OEPIH  FIRST  SEATCH  . • > 

BEGIN 

CA-.C  SEARCH  OIRECTION  OF 
l:  BEGIN 

!•  OIRECTION  <====  SON  •> 
i:=PROC  RB  TREECNOOEPTR J. FIRST  SON; 

j:=nooeptrt 

IF  I VO  THEN 
BEGIN 

(•  AS  FAR  AS  NODE  HAS  BEEN  VISITED 
<•  GO  ON  TO  THE  NE»T  NOOE. 

WHILE  (PROC  RB  TREEC II  .M ARK s • V • ) 00 

begin  j:  = i ;“t  :=p.roc  rs  treec  i i.fi  rst  son; 
IF  Iso  then  goto  too; 

end; 

no  dep  tr : s i ; 

IF  PROC  RO  TREECI I. INDICAIORs*PR* 
the n"noDe:=i  ELSE  NOOEtsj; 

GOTO  ?oo; 

end; 

too:: 

N00E:*2;  NOOEPTRIrj; 

200:; 

end; 


• ) 
• ) 


2: 


BEGIN 

C»  OtRECTION  BROTHER  • ) 

I : sPR OC  P9  IREECNOOEPTRI. YOUNGER  BROTHER; 
WHILE  IPROC  PB  rPEECn.NABKs»V»»~00 

IIsPROCHB  TREECU.  YOUNGER  BROTHER! 
NOOEPTRrsi; 

IF  PROC  RB  TREECU.  IND IC A TOR s *PP • 

then~node:si  else  aooeiso; 

end; 


31  BEGIN 


end; 

eno; 


END 


!•  RESERVED  • ) 


PROCEDURE  INITIATE  PASS 2 i 

var  i:integer; 

BEGIN 

RESET!  TEXTI  I*.  RE WR I TE! TEX TT > I 
IF  NEEO  NERGE  Then  RESET(TEXT2) 

ELSE  REWRITE! ILXT2) ; 
PRO:=»SLINKAGF  •! 

FOR  i:sl  TO  LINE  LENGTH  CO  L AS TL INEC Ut s» 

for  t:=i  to  b oo“  lastlinec u:=procu; 
ptri:=i;  ptr2 : s i ; ptrj:=i; 

SF ARCH  OIRECTIONIsi; 


eno; 


nooe:=t;  nooeptr:=i;  need  more  pass:=false;  lin:si; 
colnaker:scolnaker*i; 


procedure  generate  ppocivar  buf : te x r line); 

!•  GCNERA IE  PROCEDURE  HEADING  FCR“THE  • > 
!•  PROCEOURE  CORRESPONDING  TO  THE  •) 
!•  RECOVERY  BLOCK 


var  i. d: integer; 

BEGIN 

PROIS'PROCEOURE' ; 
col:=colmaker»5; 

FOR  list  TO  LINE  LENGTH  00  BUFCMls'  •; 

Rh  NANr:=OR0C  RH_TPEErNOCt’PTh  T.FR  RB  NAMES 
PRCC  HH  TRtECUOOrPTRJ. ENTRY : s^TN’T  “ 

FOR  rrsTJ  TO  a DO  IIUFCCOL*n:sPROf  I*u; 

FOP  j:sl  TO  10  LENGTH  00  HIJFCCOL*  I ♦ J J:  sPB  NAMCCJJ! 
8UFCC0L*t*J JJsT; • ; 

eno; 


FUNCTION  HAGHIVAR  NAME : I DENT IFl ER ) 1 1 N IE GEP S 
var  i .j i ten. sum; in teger ; 

BEGIN 

i:n;  ien:si;  sum:io; 
while  ! I < = I 0 LENGTH)  00 
HEGIN  JtsOPniNAMEC  U)  ! 

if  j><,h  then  j:sj-^a  else 
sunissum.j.  ten;  ien:sie.n«io;  i;st*i; 

end; 

hashusum  mod  hash  rtpg  lengih; 

lnu  ; 


PROCEOURE  NA“E.  C"  F A T I ON!  V AIT  N A-E I K‘‘ N 1 1 F I CP  ) S 
I • A GEN'.HAC  PROCIOURE  10  CHL  A ! t NEXT  O 


% ’ 


XHIS  PAGE  IS  BEST  QUALITY  PKACIXvaau* 

*bq*  arj  so  ace 
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J 


(•  NAH£  FOR  'SAVC'  OH  •HriTCld  OR  • > 

(•  'VALIDATION  function*,  nails  nave  • ) 

<•  t he  following  form:  • > 

<•  • ) 

«•  SAVE  — — ->  SAOQnoOt  •■“.A  110032*...  • I 

«•  RESTORE  — > RSOO<100l.RS)JOi,'12....  •) 

(•  FUNCTION  ->  VT00000 I .V rooouo? . . . . • > 

(•  • I 

VAR  imnteger; 

BEGIN 

i : >oro< n Awrr i o length]); 

IF  I s? 7 Th**n 

HEGIN  NA NET  10  LE NG TM  J! a*  0 • S 
NAHEr  IO"Lt  NGTM-l  ];s 
ChRISUCCIOADINAMCC  10  LENGTH-!  ]» ) ) ; 

ENO 

ELSE  NAME! 10  LENGTH  II - 

CHR I SUCCl OROI NAREC ID  LENGTH]))); 


PROCEDURE  BV  NAME (VAR  N ANC  : I OENTIF I ER ; VAR  I : INTEGER) • 

var  j,« .stinteger; 

(•  CREATE  A BACKUP  VARIABLE  NA HE  FOR  •) 

I*  THE  IDENTIFIER  CHARACTERISED  NT  •) 

(•  POINTER  I POINTING  TO  NLVAR  LIST.  •) 

«•  ant  BACKUP  vakiable  name  has  THE  •) 


(•  ANT  BACKUP  V AH  I ABLE  NAME  HAS  THE  •) 

t*  following  format:  •> 

(•  BV000001  ,SV  000002. HVOOOOOS. o 

I • ThET  ARE  NOT  CREATED  IN  SElUtNCE.  •) 
BEGIN 

s:=u 

FOR  K:=0  TO  19  LENGTH-i  00 
BEGIN  j:=i  H00“101  i:*i  OIV  101 

NANEC 10  LENGTH-K]:sCHRIOR0IJ)*A8) S 


PROCEDURE  OBJBLK  T R ANSL A T I ON < V AR  NOCEPTR : INTEGER ) ; FORWARD; 
PROCEDURE  VALIOATION_FUNCTION;  FORkARO; 

PROCEDURE  RB  TRANSL AT  I ONI  V AR  NOOE“TH: IN TEGER ) I 
VAR  ptrs:Irratco..ptrs_length]  of  integer; 
iunteger; 

PROCEDURE  FIND  NLOC  VARIVAR  N99EP TR : I N TEGER ) I 

e i:  lo  poTnter~to  nl  var  table  •) 

I*  j:  HI  POINTER  TO  NL~VAR“TABLE  ») 

(•  BOTH  POINTING  TO  THlT  PORTION  •) 

(•  OF  THE  TABLE  WHICH  IS  ASSIGNED  •) 


a 


A?  ^ 


!•  TO  THE  PROCEDURE  OR  REC. BLOCK  *) 

(•  POINTED  TO  Hr  

!•  IF  A PROCEDURE  OR  REC.'iLOCK  IS  •) 

<•  NONLOCAL  TO  THIS  PKOCEJURE.  •> 

(•  IT  WILL  CALL  ITSELF  RECURSIVELY) 

<•  TO  FIND  ALL  NONLOCAL  VARIABLES  •) 

(•  CHANGABLE.  •) 

VAR  I.JtKtltHMNTEGERI 
C00EISTRING2; 

BEGIN 

IISPROC  RB  TREECNOOEPTR J.PTR  TO  NLVAR; 

j:sproc~rb~treecnooeptr].nc  nlvir  used; 
j:=j*i;“  ” 

WHILE  (KJl  00 
BEGIN 

cooe:=nl  var  tablecii. indicator; 
k:=nl  var  TAuLEcn.pn  10  vdtab: 

IF  ( C09E= • PR ' ) OR  ICODE-FRB') 

Then  F IND  NLOC  VARIK) 

ELSE  IF  C30E= 'TO* 

THEN  BEGIN 

FOR  Ll=l  TO  NO  NLOC-I  00 
BEGIN 

H : sNL  VAR  LISTCLJ? 

IF  I H A 1 ) AND 

(NL  VSR  lADLECNJ.INDlCATORl'CD') 

THEN  BfG IN” 

IF  NL  VAR  TABLECH-l ]. INDICATOR 
i'It  Then 

IF  NL  VAR  TABLECHJ.PTR  T3  VJTAI 
iNL'VAR  TABLI  C I J.PTR  TO  V ITA  I 
THES  GOTO  5 br;  “ " 

eno; 

end; 

NLVAR  LISTEN9  ILOCJJsl; 

NO  NLOCYNO  NTOC ♦ I i 
5br:; 

ENO 

ELSE  BEGIN 

NLVAR  LISTCNO  NLOC]:=t; 

no  nlJJcynr  nCrc*:; 

WHTLE  (NL  V!t»  T A HL  rC I ]. INDICATOR -'CD')  DU 

i:  = i*n  " 
end; 

t r-t  s 
end; 
end; 

PROCEDURE  NL  1 1)  TTPEI  VAR  ^INTEGER)  VAR  TTPP; IDEN T IF  I ! R ) ; 
V»R  J.K  .H7l  : TNTfGER  ; 
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tn: ioentifier ; 

INO  I ME  Type  of  NONLOCAL  VARIABLE  •) 
tinieo  ro  or  me  inula  i.  •* 


TAHLCC I 1. INOICATGHS* 10*  THEN 


« • FI' 

«•  POI 
BEGIN 

IF  NL  VAR 
BEGIN 

«»  SINPLE  VARIABLE  • > 
k:=nl  var  tablet  n. pin  13  votab; 
j:svait_occ  eauleck j.rcocr.7 
IF  VArI_DCL*IA  1LFCK  ).l*mc=l 
THEN  TyPP:=S1PPL£  TAcLECJI 
CL3E  GIVE  rtPCl IY?P,«I ; 

EN3  ELSE 


BEGIN 

!• 

STRUCTURE  VARIABLE 

o 

( • 

in  this  case  stop  looking 

• I 

<• 

for  r ypc  if  the  type  ts 

• 1 

( • 

ARRAY. 

* 1 

M:=  jj 

UHILFINL  VAR  rAMLEC«].INUICArORs*CO'>  00  N:sR*l i 
k:=nl  var  tarlecm ].ptr  id  votab; 

IF  (VSR  OCL  TAHLCCK  3.Ifl(3tC*3>  OR 
f varoclTamleck  j.inuICs*)  then 
BEGIN  L7=VAR  OCL  T AOL CC X 3 . T T CODE i 

TYPP:  = SIPPCE  T AdL EC L ] i GOTO  MSI 

eno; 

K:=VAR  OCL  TAMLECK3.TC0CEI 
if  structure  r ahleck 3. injii* a*  then 

BEGIN 

TYPPIsSTRUCTURE  T A JL tC X 3 . N ARE  5 GOTO  7 55* 

ENO 

ELSE  GIVE  TYPEITYPP.KI  5 
n:=h-i;  " 

(H5=I>  00 


ENO 

735 

end; 


WHILE 
BEGIN 

K:=NL  VAR  TA8LECNJ.PTR 

give _typettypp,k» ; rjt 
eno; 

« 


ro  votab; 
p-t; 


PROCEOURE  NL  10  NAME  ( VAR  ISlNTCGERI  VAR  NA*C! IOEN  TIFI ER< 

VAR  TEJ1P:SIRINGA55  VAR  COIBJOLEANIS 
VAR  LtJ.KtNMNTEGER; 

tn: identifier; 

(•  GIVE  THE  NAME  OF  NONLOCAL  VARtABLE  •> 

BEGIN 

IF  NL_VAR_TABLEC I3.IN0ICAT0R*«I0»  THEN 
BEGIN 

(*  SINPLE  VARIABLE  *1 


k:=nl  var  tablec ii.pt  r_  to  votab; 
nane;5var“ocl  tailecki.vnIpe ; 
co:*falSet 

ENO  ELSE 
BEGIN 

(•  STRUCTURE  VARIABLE 
I*  IN  This  CASE  NANC  OF  THE 
(•  NONLOCAL  VARIABLE  HAS 
!•  FOLLOWING  FORNT 

(•  THCN  STOP 

(*  BUILOING  THIS  NANC  WHEN 
( . THE  TYPE  OF  LAST  APPENDED* 

(*  COHPONENT  IS  ARRAY. 

h:ii;  co:=truej 


co  * s TRUE  2 

VhtLECNL  VAR  TAHLEt * 3. I MIC  A TORs’CO* ) 00  NIsNMI 
FOR  L:  = I~TO  *5  DO  TEB°t  L 3 ! s • *5  „ 

li-o;  k:=nl  var  tablcc nI.ptr  to  votar; 

TNI3VAR  OCL  TAHLECK3.VNABEI 
FOR  J:=T  TO  10  LENGTH  00 
BEGIN 

IF  TNC  J 3*  • • THEN 

BEGIN  LIsL^i;  TEHPCLI^T.NC  J3;  eno; 
eno; 

l:sl»i;  TEMPrL3:=*.»; 

IF  < V A R OCL  TABLECK 3.INLIC  = 3)  OR 

IVAR~nCL”TAHLfCK3.INCICsA)  THEN  GOTO  737* 
KJsVAR  OCL  TAMLEC  K 7. fCOCE ; 

IF  STRDCTUflE  TABLECK3.IN0l=*A*  then  goto  tit; 
h:=n-i; 

while  <N>=I)  00 

BEGIN 

K:-NL  VAR  T AHLrC H3.PIR  TO  VOTARI 
tn:=sTructure  t apl  e r x 3 • naRe ; 
for  j:  = i to  iB  length  oo 
BEGIN 

IF  TNC  J 3 X • • THEN 

begin  l:=l*i;  tf.mpcl3:  = tncj3;  eno; 
eno  ; 

l:=l*i;  tenpcl3:s* .• ; 
n:=n-i; 
f no; 

7 5/:; 

n hpc l 3:* * •; 

FOR  j:  = t TO  IO_LENGTH  CC  NAMCCJ3:**  •; 

WHILE  (<J<S  fO_LCNGTH>  AAO  I TE  RPC  J 3#  • . • > ) ’’0 


HE  GIN 

NAHrc  j 7 : i re  hpt  j 1; 
eno; 


j ■ • j ' i ; 


eno; 
ton:  ; 


IBIS  PAGE  IS  BEST  QUALITY  PBAOIIpj 
THOU  OQPY  guaii-^mcn  jp  _ 
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END! 


PROCCOUKE  UCL  BKUP  VAR} 

FIND  ME  NAME  ANO  THE  TTPE  OF  •> 
rm  nonlocal  variable  a.nu  TurN  •» 

OLCLAKC  A BACKUP  VARIABLE  FOR  •) 

that.  example:  •» 

if  lotNUFirR  name  is  id  ano  • > 

identifier  rrPE  13  iotthe  tmen:*i 

var  DvooooonotiOTvPt  • > 

IS  UHA  T WE  ARE  LOOKING  FOR.  • > 

WAR  I > J • K : INTEGER; 

ttpp  » name : t cent i f i er  « 
r:«p:srRiNG«s; 
co: 'toole  an; 

BEGIN 

FOR  l::|  TO  LINE  LENGTH  00  RUFERCl):=*  •; 

BUFEKC COL» T 3:  = »wF;  OUFERC  COL*  A Its* A* 5 
DUF tHC  COL*0 1 1 s *R  * ; 

PUT  LINET  TExT2,BUFER,PTR2>; 

FOR  Its!  TO  NO  NLOC-1  00 
BEGIN 

FOR  Kt  = I TO  LINE  LENGTH  30  0'JFERCKI:  = * •; 

k:=nlvar  lssteiot  name:=*evooooo3*; 

3V  NAME  CflAME • I > ; 

FOR  j:=1  TO  10  LENGTH  CO  BUFERC C0L*J»3 J: = NAMF C J1 J 

j:=col*jo; 

NL  10  NAHEIK. NAME. TEMP, CO) S 
NL  I 0—T  TPE (K.TYPP). 

FOR  KT=l  TO  10  LENGTH  CO  BUFERC d*K- 1 J: sNAMF.C X J ; 
auFERCK»j-n:=F:« ; jisk.j; 
for  k :=i  to  io  length  co  euFERC k » j j: s t tprck i ; 


buferck*j }:  = • ;T; 

PUT  LINETTE  •-  - 


TEX  T 2 ,BUFER  »P  TR2  M 

C0Ll=C0L-4. 

ENOt 
END  I 


PROCEDURE  PROC  HEADING!  WAR  PSNR  *.  10ENT  l FIER  >T 
€•  GENERAT"  PROCEDURE  HE AO  I NG  FOR  •) 

<•  SAVE  ANO  RESTORE  PROCEDURES • •> 

(•  PSWR  CARRIES  THE  NAME  OF  THESC  •) 

(•  PROCEDURES..... .) 

var  i.j: integer; 
cmnt:strin6I6; 

BEGIN 

PRO :=♦ PROCEDURE* I 

FOR  I Jsl  TO  LINE_LENGTH  00  eUFERCIlJs*  »i 

for  !:so  to  a oo~buferccol*I  j:=PROcf*n; 


I*  SAVE  •)  • 

<•  RESTORE  *)»; 


end; 


BUFERC  C0L*I3:  = * **.  NAME  CREA  TION  (P3VR  ) I 
FOR  Jtsl  TO  10  LENGTH  OTJ 
BUFERCC0L*I*J*lJ:sPSVRCd3; 

BUFERC COL- I*d* lots*;*; 

IF  C0DE=1  THEN  CMNT:=* 

ELSE  CMNTIs* 

i :=coL*i*'d*2; 

FOR  Jtsl  TO  1 A 00  BUFERC I * J ] t =CMN TC d 3 ; 

PUT  L I NET  TEX T2 , 8UFER »PTR2 1 ; 

proTs'Begin  »;  

FOR  list  TO  LINE  LENGTH  DO  BUFERC  Ills*  •*. 
FOR  l:*0  TO  R OO“OUFERCC0L*I*3]:=PROCI*n; 
PUT  LINEITEXT2.0UFER.PTR2>; 


PROCEDURE  SAVE  VAR; 

GENERATE  3TAENENTS  FOR  THE  HOOT  OF 
SAVE  PROCEOURE.  THE  STAEMfcNTS  MUST 
BE  ABLE  TO  STORE  THE  ORIGINAL  VALUE 
OF  NONLOCAL  VARIABLES  INTO  THE  HACK 

UP  VARIABLES ... 

var  i,d,K,L*M: integer; 

nahe:ioentifier; 

NAMtOOUOLE  10; 

tfigtring^s; 
cotboolean; 

BEGIN 

COOEtsi;  PROC  HE  AO ING  < RVS ) ; 

FOR  t:s|  TO  NO  NLOC-l  00 
BEGIN 

FOR  Jt  = l TO  LINE  LENGTH  00  BUFERC  J It  = * »! 
NAME:i»'W300000*T  HV  NABEINAME.I) ; 

FOR  j:=l  TO  10  LCNGTH~CC  NAMCJ]:=NAMECdi; 

K : sNL V AR  listctj; 

NL  IJ  NAP'IK, NAME. TE. C0>;  , , 

FO*  JT=;  TO  10  LENGTH  CC  NAMCJ*IO  LENGT H ] t r WA MIC J I 
FOR  dtsl  TO  10"LENSTH«2  DO  BUFERC COL» J* A 1 1 sNA^T  J1 S 
HUFEPC  COL  ITr* : • i BLFERC  COL  *d.5 It  s 1 s * ; 
d:  scoL*d*G; 

IF  CO  THEN 
BEGIN 

FOR  l:=i  to  AS  00 
BEGIN 

IF  TEC  L I*  * * THEN 

begin  m:sl;  BUFi:KCd»L-i  i:  = tecl  j;  cnj; 
lnu  ; 

nu.*ERCd.m:=* ; • : 

f NO 

ELSE  begin 

for  l:=i  to  io  lfngth  oo  iiuferc  j*l-m:  = 
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nahecl  IS 

BUFERC  J*L  1 !s  • l • I 
end; 

PUT  LINES  TEXT?  .BUFER.i*  TK?>  » 

COLTiCOL-‘J; 

ENOS 

pho:=*eno;  • i 

FOR  k:si  to  line  lfngth  oo  uufebck l: *•  • • 

F 01  >::.l  TO  T O0-HUFF.RCCJL»KK  = PROCX»1J; 

PUT  LINES  T£x  T?iHUFERtPTR?)  S 
COLTiCOL-JS 
ENOS 

PROCE0URE  RESTORE  VARS 

(•  GENERATE  STAEHfN  TS  FOR  THE  ROOT  OF  •> 

<•  RESTORE  PROCEDURE • THESE  STAERENTS  •» 

S*  HU'JT  HE  ABLE  TO  STORE  HACK  THE  •> 

(•  ORIGINAL  VALUE  OF  nonlocal  variables*) 

<•  from  backuh  variables  into  the  wars  •) 
var  i,j.k.*«l:inieger; 
na.re.nasioentifiers 
nap:uojhle  ios 
tesstringa?; 
co : boole an; 

BEGIN 

C00E:s2S  PROC  HE AOINGIPRV ) S 
FOR  l:*l  TO  N0~NL0C-1  00 
BEGIN 

FOR  j: =1  TO  LINE  LENGTH  00  BUFERCJ3:=*  *i  j:=COL**S 

k:=nlvar  listc  I jT 

NL  ID  NAPE<K.NAHEiTC«CO>; 

IF“CO“THEN 

BEGIN 

FOR  h:=i  TO  *5  00 
BEGIN 

IF  TEC R 3**  • THEN 

BEGIN  LISNS  BUFERCJ*R-n:  = TECN)S  ENOS 
ENOS 

BUFERC J*L 3I  = * 5*  S BUFERCJ*L*l3Ss'=,5 
j:=j*l»2S 

ENO 

ELSE  BEGIN 

FOR  m:=i  TO  10  LENGTH  00 
BUFERC  J*H-n:  = 3ANeCN  JS  , 

BUFERC J*N-l 3:=» ;• S BUFERC J*N 3I=‘ =• S 

j:=j*“*is 

ENOS 

NA;s*BVOOOOOO»  S BV  nafetna.ds 

FOR  L:  = l to  10  LF.NGTfl  CC  NARJL  3I*NACL  3S  . 

FOR  Lt  = l TO  I0"LENGTH  CC  NINE  L*  10  LEN6TH3  5 sNAMEC  L 3S 


S8?E^:ijIl3”TS?;GTH*2  00  8«^RCLRj-n:=NANCL3; 
C^T^S^;fXT2’BUFER'PT"2,{ 

ENOS 

PRO:=»ENOS  *5 

FOR  k:=1  TO  LINE  LENGTH  00  BUFERCK3:=*  • s 

f8?,LKiN"«f«?2«RF^tCR?ttK3:  = P,,OC,(*13* 
colt=col-js 

ENOS 

NAIN  BOOT  OF  RB_TR ANSLAT ION  •) 

BEGIN 

5S-2P „procclin3j=nooeptrs  lib:=lim*i s 

NO  NLUC .-l • 

£2*  I:r3  T0  PTRS  LENGTH  00  PTRSCI3:=0S 

GENERATE  PROCTBUPtKIS 

PUT  L I NET  TEX  T? • BUFER |PTR2) 8 

PINT]  NLOC  V AR  ( NODEP  TR  ) S 

DCL  ?KUP  VARS 

SAVT  VAR7 

RESTORE  VARS 

I'JOIClilS 

V AlTOAT ION 'FUNCTION S * ' 6ET.LINE(TEXTI,BUFE«.PTRnS 

IN0IC;:2S  “ 

GiT.LlNETTTXTI »TEMP  STRTfPTRt)S 
GET_LINE(  TfJXTl.  TEHP“S T«S T ,PT R 1 1 1 
Gtr  LI. NEC  TF.X  T1  • Tf  M p-ST'<  T , ’ T R 1 ) S 
08JBLK  TRANSLATIONTITOOEPr.T); 

ENOS 

PROCEDURE  VALIDATION  FUNCTIONS 

var  rrsr. r:sTRiNGT/s 
tstsstking  to; 
i.j.kk.k.n: integers 

BLANK  MOOLEAN; 

PROCEDURE  SUBSTITUTE  PRIORSVAR  IES  T : S TR I NO  A 7 S 

var  parings;  v4* 

n<ii,l<c.u.v:  integer; 
ioi siuentifier; 
loro:no/,jLr  in; 

«•  WHENEVER  T He  TfRR;  PRIOR(XXX)  APPEARS  •> 

(•  IN  THE  VALIDATION  TEST  »)C PLACE  IT  MT  •) 

S*  THt  HACK  UP  VAR  | A HL  r FG»  III.  »> 

!*  I;1:  PR l or ( « xx » mill  n f fo  and  •> 

{*  fJ-rUSr.i*'’’  HL4C<-  HW013JS.-XXX  MILL  BE  •) 

I*  INjLRrUt******.****,,.,,,... « I 

4UIN  1 
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xx:=os  o:=is 
for  n:  = i ro  x-s  oo 

ULGIN 

for  l:-i  ro  5 oo  PCL3:=re4TCN*L-i 3; 

IF  P=*P«IOR*  THEN 

UEGIN 

FOK  LJ=0  10  N-t  00 

wee, in  kk:=kk*is  tckk  ):  = testcl  3s  ends 
o:=ns 

while  rresrto !*•*•»  oo  u:=c*i;  o:=o*i; 

n: sQ-i ; 

while  i re stcn J* • ( • > oo  n:=n-i:  n:=m*is 
for  s:  = i to  io  length  ct  101103:=*  •;  g:=is 

WHILE  ( N<0-1  T 00 

hlgin  idics j:=ir gtcnj;  n:=n*is  s:=s»i;  eno; 

for  u:=i  ro  no  nloc  oo 

begin 

S*.=NLV»R  LISTCU1I 

IF  NL  VAR  TAHLECSa.INCICATORsMO*  THEN 
BEGIN” 

G:=NL  VAR  TAJLEC  5 3.FTR  TO  VOTAHI 
IF  VA*  UCC  TABLEC'.3.VN*KE  = tOI  THEN 
BEGIN  ” 

f or  v:  = i to  id  length*?  no  iomrv3:  = * »; 

FOH  v:  = IO  LENGTH* 1 TC  ID  LENG  Th  *2  30 
ididcv3:=Tdicv-io  length!: 
ioi :=*ovoooooj* ; ,»v  nahe( idi *u> • 

for  v:=i  ro  io  lenjtr  do  ioiucv ::  = ioicvi; 
GOTO  1731 
ENOS 
ENOS 
ENOS 
1 73  * S 

FOR*V:s|  TO  to  LENGTH*?  00 
BEGIN 

IF  ID10CV3**  • THEN 

BEGIN  KX:=KK*1S  TC  K K 3:  = 1 0 IOC  V 3 S ENOS 
ENOS 
ENOS 
ENOS 

FOR  l:=o  TO  K 00 

BEGIN  KK:=KK*i:  TCKK 3:=r£jTCL3i  ENOS 
for  l:=i  to  kk  oo  testcl3:*tcl:s 
ENOS 

C*  NAIN  BOOT  OF  VALIDATION  FUNCTION  • > 

BEGIN 

(•  GENERATE  STAENENTS  FOR  THE  VALIDATION  •> 

I*  FUNCTION  HEADING  ANO  ITS  BOOT.  *1 

test:=*function  jbooleans  <•  validation  •)  *s 

FOR  U = l TO  LINE  LENGTH  00  BUFCI3:=*  *S 


NANE  CREAT IONT  FNTl S 

FOR  T:  = l TO  10  LENGTH  00  TES  TC  I *9  3:  =FN  TC  I 35 
FOR  II=l  TQ  AT"00  HUFCCOL* I- 1 jl =TESTC 13, 

PUT  LlNE(TEXT2,eUF,PTR2>  ; 

FO«”l:=l  TO  LINE  LENGTH  00  BUFCI3:=*  *5 
PRO  S = * BEG  I N *7 

FOR  i:=l  TO  9 00  BUFCC0L*I*2 3:=PR0C I 3S 
PUT  LINE < TEX T2,HUF,PTR?)  5 

test:=*not<faultflag)  ano  i 

FOK  i:  = l T 3 LINE  LENGTH  DO  BUFCI3:  = * *S 

FOK  i:=l  TO  10  LENGTH  CO  BUFC COL ♦ I ♦ 3 3 ! =FNTC 13! 

BUFC  COL *1 *3  3 : =T ; • ; BUFC  COL»I  *A  3:  = * = * S 

I :=col*i*g; 

for  j:=l  TO  20  00  BUFC l*J-13:=TESIC J35 
i:=:*J!  j:=is 

while  (hufercj:=*  *t  do  j:=j*is 

while  <dUFERCJ3»*  •»  oo  j:=j*i; 

while  ibufercj3=*  • > oo  j:=j*i; 

for  x:=i  ro  at  oo  testck3:=*  •; 

x:  = is 

REPEAT 

testck3:=bufercj35  k:=k*is  j:=j*is 
BLANXISTRUES 

FOR  h:=J  to  line  length  00 

BtGIN 

IF  8UFERCN3#*  • THEN  HL ANX : =F ALSE S 

eno; 

UNTIL  (BLANK): 

SUBSTITUTE  PRlORCTESr.K.KKU 
fo?  j:=i  T!  xx  no 

HEGIN  IIUFI  I I:  = TESTCJ  3?  I:  = I*I5  E NO  I 
hufci3:  = m«;  nuFCi*i3:  = *5»s 
PUTLINC(TCXT2»BUF,PTR2I l 
col7=col-*s 

FOR  t:  = l T 3 L l Nr  length  oo  mjFCI3:  = * •; 

auFC col J:=*e * s hOfccol*! j:=*n*s  eufccol*23:=*0' s 
ruf £ col* 3 3:  = • ; • ; 

PUT  LINE! TC X T2.HUF ,PTR2» S 

PROC  *11  TREfC NOOEPTR j.PTR  TO  ENO  0CL:  = PTR2-IS 

col:=coC-3s  - - - 

j:=col  ; 

fo”  i:  = i t 3 line  length  oo  iufci::  = * *; 

PMO:s*tLlNXAGE  *7 

fo”  I r = t ro  -»  no  wufci  j:=P?nc  n; 

IF  PROC  RM  I Af'  INQOt  PTP  ) • F I A S I GCNJO  THEN 

Hf-.IN  Pur  L IN' ( TEX  T2.CUF  ,PT  R27s 

inj; 

col:=j; 

prj:s*m,'cin  *t 

FOK  I S = t T)  Line  L*  N GTm  DO  U/KI3:  = * *S 
fok  t:=l  10  9 U'J  iHJFC COL *1*1  3S  = PAQC  I 35 
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PUT  LINE(TrxT?,nuF,PYR2) ) 

isyTs'faultflai.isfal'.e;  ; •; 

for  i:  = i ro  in  length  no  Tire  ii*n;  spvsc  I is 


FOR  i:  = l TO  Ltflt  LENGTH  00  <U»-C  I 3 1 =•  ’! 
FOR  JJrJ  TO  30  1)0  IIUFC  COL*  I • 5 j!  s IS  TC  13! 


PUT  LINE!  TEX  T2.HUF  ,P  TR?>  5 
LNU!  ~ 

PROCEDURE  OHJHLK  YRANSL A T t ON! 

VAR  ENS  cnt:iitegh<; 

PKE7  WORD. NEXT  yORO.’STRINGlOJ 


• > 

* I 

• ) 

• I 

• I 

•» 


PROCEDURE  CREATE  ENOi 

GENERATE  The  END  STAEMENT  FOR  THE 
TRANGLAIEO  RECOVERY  BLOCK. 

EX  APPLE  I 

i35t:enu; 

LAHLES  are  13*37,131.7,1  17  7,1  38/,... 

USE  3 FOR  RECOVERY  BLOCKS  AS  THEY 
APPEAR  IN  TEXT *1 

var  j,k: integer; 

BEGIN 

KIiPROC  R8  treecnooeptr j.lahle ; 

FOR  j:  = t to  line  llngtf  00  BUFtRC  JO;-* 
j:=col>  fill  aOr  fi elo< eufer.j.k > ; 
l»uferCcol*a  ]:=t:  • iuferccol*g  3:  :»e*  i 

BUFERCCOL»ft  l;=»N» i BU FEKC COL* Ml s • 0 • ; 
BUFEKLCOL*!^^ ; • 5 
PUT  LINE(TEXT2,0UFER,PTR2)S 

eno; 


PROCEDURE  GIVE  NEXT  UOROJ 

var  i,j:intcger;~ 


FUNCTION  HOREI VAR  TX  : INTEGER)  IBOOLEANS 

var  j:integer; 

BEGIN 

rore:=true; 

FOR  j:=TX  TO  LINE  LENGTH  DO 
BEGIN 

IF  TEMP  STMTCJ3  »•  • 

ENOS 

end; 

PROCEDURE  PASS  QUOTES! 

var  i,j: integer; 

BEGIN  1 :■=  0 s 

IF  TENP  STMTCTXT  PTR*l3="»* 


then  more:=falge; 


. . ..  ...  . __  THEN  l:=TXT  PTR»1 

ELSE  IF“TENP  STHTCTXT  P1R*23='*"  THEN  ~ 
I:=TXT  PT8*2T 
IF  I * 3 T H E N 
BEGIN 

I : -!♦! s j:=ii 


WHILE  (J  NOD  2 »0>  00 
BEGIN 

IF  TEHP  STNTCI Js  • •••  THEN 
BEGIN  “ 

WHILE  (TEHP  STHTCIJs""!  00 
REGIN  i::l*l! 

eno; 

ENO 

ELSE  l:  = I*H 
ENO! 

txt  ptr:=i; 

PAS5_QU0TES! 

ENOI 

ENO! 


PROCEDURE  PASS  COMMENTS  I 
ER! 


VAR  IIINTEGERi 
BEGIN  I!=TXT  P TR ♦ 1 ! 

IF  NOT  MORE (T>  THEN 
BEGIN 

WHILEtTEMP  STMTCITs* 
I F ( C TEMP  STMTr 


•»  oo  i:=i*i; 


I F t ( TEMP  STMTtns'CM  ANO 

<TEHP-STHTCI*l  Js'.MI  THEN 
3EGIN  i:ti*i; 


eno; 

eno; 

MAIN 


ENO! 


REPEAT  l:?I*U 

until  t ( temp  srFrm=*»«>  and 
(TEMP-STHTCI*niM»)>; 
TXT  PTHlii; 


OOOY  OF  GIVE  NEXT  WORD 


• > 
• I 


WORO! 


THEN 


<• 

(* 

BtGIN  IN0IC:=2S 

PREV  WORO:=NEXT 
PASS“QU3TES 1 
PASS'COMMrNTS! 

IF  NORLCTxr  PTR  ) 
begin 

PUTLINF ( TtxT2,TFMP  SIRT.PTR?)! 

GE  T LI NF ( TE X T I , TEMP"S I M T , P T R I > i 

eno; 

TOFFN!?*  t;  I:=rxT 

WHILE* ( KLINE  LENGTH*  tvo 

<N0r(llRc  St “It  I 3 IN  SYMBOLS!) ) DO 
IF  [iLINL  LENGTH  THEN 
BEGIN  PUI 


PTRS 

IS  =1*1  * 


ENO; 


PUT  LlNLirF.XI2tr-.MP  STPT,PTR2), 
e.et^l  ine(  irxri  ,t:mp*  -.r»  t.ptri)  ; 

WHtLLINOTI Tt MP_S  T M f 1 1 3 IN  SYMBOLS))  00 


I ; ■=  I * t ; 


1 
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JHIS  PAGE  IS  BEST  QUALITY  PRACIICAiU*! 
ISOM  CSCXFY  mailSHED  10  DOG  


JJsiS 

WHILST!  Krl.lNC  LENGTH!  ANC 

TTF1P  SPATE  I]  IN  SYMBOLS!)  00 

begin  tokcnCj 3:= icmp  srmili  euj; 

rxf  prx:  = u 

Fon~i : js  i to  10 

IF  NEXT  WOKOEU 
IF  ! IOK  rN- ’ELSE 

eno; 


oo  nfxt  wohjc  nr-roKtor  I j; 
in  then  give  next  ^.j’o; 

ERROR  >1  THEN  CECI-'M  <!-Xl 


PROCEDURE  CREATE  IF  THCNI 

(•  GENERATE  5T  AC “r  N TS  FOR  T HE  SCOT  OF 
(•  PROCEOUKE  CORRESPONDING  TO 
<•  THE  TRANSLATED  RECOVER!  BLOCK. 

t*  example: 

«•  IF  VTOOOOOl  THEN  GOTO  1357 

<•  ELSE  BEGIN  RSOOIOOII 

T»  FAUETFLAGIsFALSE; 


O 


ENO • • > 

VAR  TF  MPl  1 ST  ril  NG4S  I 
TE  MP2 IGTRINGATS 

i.j.k: integer; 

BEGIN 

TEMPI  : s*  IF  THEN  GOTO  («  El 

for  i:=i  to  to  length  co  TtMDici*3i:iFNrri j; 

FOR  t:  = l TO  Line  LENGTH  JO  H'JFlRCMIs'  ' • 

IF  C0L*44  >LI N£  LENGTH  THEN  CJi:=LINE  LENGTH-451 
FOR  t;sl  TO  45*00  TUFERt COL*I-l j:  = terpic I I! 
XJSPROC  RJ  TREECNOOEPTR  l.LATLE;  j:sC0L»12; 

FILL  AOT  FTELOChUFER,J,K!I 
POT  CINETTEX T2 .OUFER ,PTR2>  1 
TEHP2 I 5 ' ELSE  BEGIN  i F AUL TFL AG  I =F AL 3E i ENOS 

for  i:si  ro  io  length  co  TtNP2C  i»m:=PRvcn; 

FOR  I := V TO  Line  LENGTH  JO  VJFEBC I J:=  • •; 

IF  C0L*4d>LINE  LENGTH  THEN  COL : =L INE  LENGTH-40} 
FOR  i:  = l TO  4 7~00  BUFERC COL ♦ IJ : = TE MP2C I) • 

PUT  LINET  TEX T2 » BUFER »PYR2 ) ; 

eno; 


PROCEDURE  ERROR  MESSAGE  > 

<»  GENERATE  ERROR  MESSAGE  FOR  THE  •> 

(•  CASE  THAT  ALL  ALTERNATES  OF  THE  •> 
t • RECOVERY  CLOCK  FAILED.  •> 

var  temp:string45; 

TEMP2:STRING4T5 

nameiioentifier; 
i,  j,k: integer; 

BEGIN 

TEMP  J s • IF  THEN  GOTO  (•  EXIT  •) 

FOR  I : = 1 TO  10  LENGTH  00  TtMPCIOO:=FNTt  ij; 
for  i :=i  ro  litje  length  oo  bufercm:  = ' •; 


IF  C0L*44>LINE  LENGTH  THEN  COl:=LINE  LENGTH-45! 

for  i:=i  to  45  oo  buferccol‘1-1  i:  = tet»pci  j; 
k:=p*oc  rb  treecnooeptr j.lable;  j:=col*22; 

FILL  AOT  FTELOTBUFER.J.O ; 

PUT  CINETTEX 12  * BUFER » PTR2 ) i 
TEMP7= 'ELSE  BEGIN 

FOR  i:  = l TO  45  00  BUFERC  COL-*I-l  31  = TEMPC I It 
PUT  LINETTEXT7.HUFER.PTR2>; 

FOR  list  TO  L INE  LENGTH  00  BUFERC I JJ  - • •} 

TENP2:  = ,WRITELNI  "RECOVERY  PRlCEOURE  FAILED''!;'; 

NAME t APR OC  RH  TREECNOOEPTR J.PR  RB  NAME! 

FOR  j:-l  TO  10  LENGTH  CO  TEHP2rj»29 K=NAMECJ I} 
IF  C0L*5T>LINE"LENG TH  Then  cgi:=line  length-sb; 
for  i:=i  to  4 7“  oo  bufeRC  col  » I ♦ i o j : a tE  *<p?c  ij  ; 

PUT  LINETTEXT2, BUFER, PTR2> ; 

for  j:=i  ro  line  length  oo  hufercj3:='  •; 
temp;=»faultflag:^ true; 


f) 


t 


FOR  Ilsl  TO  ID  LENGTH  00  TEMPt I*173:=PRVC n: 

tempci*i7J:=';t} 

FOR  j;  = l TO  ID  LfNGTH.21  00  01  FE  RE  COL  ♦ J- 1 J : = T r'<°C  J I ! 

PUT  LINET TEX T2THUFER ,P?R2> j 

F0R~j;=1  TO  LINE  LENGTH  JO  HJFERCJj:*'  '} 

buferc col -6 3:  = 'ey;  huferccol-s  j;  = 'N» ; 
buffrccol-4 i; a'o* ; bufere col-3 j:=' ;• ; 

PUT  LINETrExr2, BUFER, PTR2> ; 

colT=col-i2; 

eno; 

PROCEDURE  travel; 

T»  WHEN  There  ARE  NESTED  RECOVERY  OLOCXS  »> 

(•  JUST  TRANSLATE  the  outer  one  and  SKIP  o 

I»  OVER  The  INNER  ONES....... .) 

var  i,j: integer; 

BEGIN 

inoic:=?; 

WHILETEN3  cnt>o>  do 
BEGIN 

GIVE  NEXT  word; 

If  next  wOHOs’ENSURE  • THEN 
HCGIV 

NEr  0 MORE  PASS:  = TRUE; 

3;ai  To  id  length  oo  iocjjisprev  wor'iC.it; 
i::hashtiu>;  “j:=ha3r  pt»gci5; 

WhILETIO  » HASH  TAHLEC3J.PR  NAME!  OJ 
BEGIN 

REPEAT  t:*TI*t>  MOO  HASH  PTPS  LENGTH! 

UNTIL  (HASH  PTRiCM  0 'J  > T 

j : -hash  pirgeTj; 
end; 

OLUPTR  HHASH  rAILrC  JJ.PTR  TO  PROC  tree;  , 

PROC  RH  iRfErOLOPTXJ.  NIRT:-?TR’-Ji  114 


ENOS 

IF  NEXT  WOROiMlFGIN 
ELSE  IF~NEXT  WOHO-*F>i 


• IHFN  ENS  CNTtsENS  CNT.I 


tmcn  tns  cntTiens  cnt-i; 

ENOS 

ENOS 

(•  MAIN  BODY  OF  OBJrtLK  TRANSLAIION  .) 

OCGIN 

OLOPTWS-NOUEPTRS  INOIC:=2S 
GIVE  NEXT  WORD  S 

WH I LE (NEXT  WORD  ■ 'ELSE  ERROR*)  00 
BEGIN 

IF  NEXT  WORO=*ELSE  BY  • THEN 
BEGIN  ■ 

CREATE  IF  THENS 

GET  LlH'lTExTl.TrMF  STMT.PTKDS 
GET"LINt( TEXTl,TENP_GTFr,PTRI)S 
GIVE  NEXT  WOHOS 

IF  NEXT  WORD- 'BEGIN  • THEN 

BEGIN 

ENS  cnt:=is 
TRAVEL  S 

PUT  LINCITEXT2, IEMF  STMT,PTR2)J 

END 

ELSE  PUT  LINEITEXT2.TEMP  STMT.PTR2); 
GETLINrTrExri«IEMP  stmttptkd; 

GIVE  NEXT  WORDS 

IF  NEXT  wO«0=*tLrNKA3E  • THEN 
GET  C I NEC  TEXTl.TEMP  STP  T *PTRl ) 

ELSE  GOTO  250 S 


ELSE  IF  NEXT  UORO=*8EGIN 
BEGIN 

ENS  cnt:=is 
TRAVELS 
ENOS 

GIVE  NEXT  WORDS 
— 


* then 


250:7 

ENOS 

ERROR  MESSAGES 
CREATE  ENOS 
ENOS 


MAIN  BODY  OF  PASS  2 


INITIATE  PASS2S 
WHILEiNEED  MERGE)  DO 
BEGIN 

(•  WHEN  NEED  MERGE  IS  TRUE.  VF  HAVE  •) 

(»  NEW  TYPE  DECLARATIONS  GENERATED  »> 

(•  BY  PASS  l.  THESE  NEW  TYPE  UCL*S  •) 

(•  ARE  IN  A FILE  CALLEO  TEXTi.  MERGE  •) 

I • THEM  INTO  THE  MAIN  TEXT 

n:=pos  new  t ypf  » i ; 

FCOPYITExTT. TEXT3.8UFER.PTRl ,FTR3 ,N>  5 
IF  DCL  TYPE  THEN 

BEGIN  FOR  Ilsl  TO  LINE  LENGTH  00  SUFERC  M: s*  *S 
8UFERC23:=*T»S  HOPE  RC  3 3:  = « Y « 5 
BUFERC ♦ 3 : = • P • I HUFERC 5 3: =*E • s 
PUT  LINE(TEXT3.BUFER.P1R3)5 

ENOS 
N a • 1 S 

whTletbufercni  =•  •)  oo  n:s>i*is 

WH ILEI NOT  E0F(TEXT2))  00 
BEGIN 

for  i:=i  to  N-i  oo  bufcu:  = * •;  j:=n; 

WHILEUNOT  E0LMTEXT2  ) ) AND  CJ<=LINE  LENGTH))  00 
BEGIN  READ! TEXT2.0UFCJ3) 5 J:=J*15  ENOS 
KEAOLNI TEXT?) S 

FOR  l:=J  TO  LINE  LENGTH  00  0UFCI3:=*  *S 
PUT_LINF( TEXT3.HOF.PTR3) 5 
ENOS 

NELO  merge:=falses 

ENOS 

PTR2:M5  HEWRI  TETTEXT2); 

WHILE  INOOEIO)  DO 
BEGIN 

IF  FIRST  CALL  THEN  DCL  FAULTFLAGS 

first  caCl:-=falges 

NEW_NOOt(SEARCH_OIRECriON)S 

<•  NOOEsO  » TREE  HAS  BEEN  VISITED  •) 

<•  N00r  = l > PROCEDURE  •) 

(•  N0UF=2 •>  TERMINAL  NODE  IN  TREE  •) 

<•  NO 0*  =3 > REC.ULOCK  NOOt  •) 

«•  BY  NODE  WF  MEAN  A NODE  ON  THE  ») 

<•  PKOC/RH  TRFE 

CASE  NODE  OF 
i:  BEGIN 

n : -proc  p >«  trite nooeptr 3. entry; 

FCOPYI  TFxrT,  P.X  T3.H’JFER,PT  (I,PTR3.N)5 
SI  ARCH  DIRECTION;: I i 
P*OC  »n  TRt  EC  NOOFpTR  3* MARK S : * V * S 
ENOS  " - 


2:  BLGIN 


OTIS  PAGE  IS  BBSI  QUALITY  PSACSiftA*** 

jjjom  oopi  nnnus*™  ro  dcc 

■ 


I :=pi*oc  R'i  treecngolftr  3. younger  hrothcp; 
while  (T^T  00 

BEGIN  NOOtRTRjsPROC  R*l  I REEt  NOOEP  T S ).F  A IHC  ' I 
ir  nodipthsi  The?! 

BEGIN  NOOE:sO;  GOTO  I'lll  ENO 
llgt 

i:*P«OC_RB  rBEtCNOOEPTB  ). YOUNGER  BROTHERS 

END  t 

JS-PROC.RH  TREECNOOEPTRJ. YOUNGER  0®0TM<:RS 
IF  PROC  PP  TRE'.IJ J.NAHK=*V* 

tm«-n"ulcin  nouepir:  = i;  search  direction:!!; 

END 

ELSE  SEARCH  DIRECTIONS^; 

55015 

ENOS 

3:  BEGIN 

FINO  ELOER  BROTHER; 

CASE  ELDER  BROTHER  OF 
i:  BEGIN 

<•  ELOER  eROThFR  IS  NULL  •> 

!•  OR  A 

k:=PROC  RR  TREtCNCOEPTR  i. father; 
n:=proc_rb-t>el[o.ptr  io  rNn  dclm: 

FCOPYC  TCXTT,TEAr5.BUFERfPTRl .PTRS.N); 
inoic:=j; 

GET  LINE! TEXT l ,BUFER»PTRl> ; 
j;-To ; 

FILL  AOR  FIEL0I3UFER.J.PTR2) ; 

PUT  EINETTEXM.H.JFER.PTRJ); 

PROC  R9  TREECRj.PTR  TO  END  OCLSsPTRJS 
NS  = PPOC  RH  TREtCNCO'PTPI.ESUr; 

FCOPYI  TExn.rExIitHUFER.PTRl.PTRJ.NI  ; 

indic:=s; 

GET  LINEITEXTl .BUFER.PTRIIS 
RB  TRANSLATIONINOCEPTR); 

create  linkage; 

NOOEPTPSsOLDPTRS 

IF  NOT  YOUNGE R INOOEPTR ) THEN 

RUT  LINE! TEXT2,LASTLINE,PTR2>S 

search  directions^!; 
eno; 

2:  begin 

(•  ELOER  BROTHER  IS  REC. BLOCK  •» 

n:=proc  r b treecncdertrj.entry; 

FCOPY(TEXTT,TEXT3.0UFER.PTRI ,PTR3,N»; 
inoic:=3; 

GET  LINEITEXTl  ,BUFER«PTRl)J 
j:=To;  i := i o ; 

UHILEILASTLINEtn  »•  •>  00  IS=I*1S 


i r = i - 1 ; 

CONVERT  DECIMAL (LAS TL INC ,0 ,1 »K); 
I!=PROC~RB  TREECNOOEPTR  1. FATHER! 
PROC  RHTREEC  IJ.PTR  TO  ENO  DCLS=KS 
RB  TR AN5L  AT  I ON (NOCEP  TRT ; 
create  linkage; 

NOOEPTPS=OLQPTR{ 

search  direct iun:=i; 


• > 
• ) 
♦ I 


inoicatdrss'pam 


END 
ENOS 

ENO 

ENOS 

ENOS 

(•  CHANGE  THE  NOOE  INOICATOR  OF 
(•  THOSE  REC. BLOCK  NODES. WHICH 
I*  ARE  TRANSLATED  INTO  PROCEDURE 
FOR  IS=l  TO  LIM-l  00 
BEGIN  NS=RB  TO  PROCCMJ 
PROC  PH  TREECNI.I 

ENOS 

inoic:=is 

REHEAT  GET  L INE I TEX T1 . BUFER  .P TR 1 > S 
PUT  LINE (TEXTS, QUFERtPTIUI S 
UNTIL  (EOFlTEXTl))! 

ENOS 

PROCEOURE  PRINT  PROC_TREES 
VAR  ISINTEGEPS 
BEGIN 

WRITELNI*  ....  PROCEOURE  TREE, VARYING  COMPONENTS  . 
WRI TELNSWRI TELNS 

WRITELNI *PIOC  NAME  * » * TND  I C A TOR  * « ’ ENO  OF  OCL*. 

• ENTRY*.'  HARK*)S  WRITE LN 5 
FOR  i:=l  TO  NEXT  PROC  NODE-l  DO 
WRITELNIPROC  R'<  TREECTl.PH  KB  NAPE.*  *. 

PROC~R  1~TREECI  ].lN3IC3rOR. 

PRJC-Rn“THEf Cl  ].PTR  Tt  ENO  OCLSlt. 
p«oc“Ro~TRrfci ueniPy:!,*  “ *, 

RROC-RH-YHCCC I 1. MARK  1} 

WRI TELNS WRI TCLNT 

enu; 

PROCEDURE  MERGE  INTXTIVArt  TE X T 3 , T f a r ’ , IF  X T l : TEX T FILE ) ; 
(•  MERGE  TEXTS  INTO  TEXT,? >TtxTI  •) 

var  i . r ,k; integer; 

BEGIN 

inoicssi ; 

NT  SI  ttTl'XTSMt  RFSTTI  TF.XT  si  j I T«‘fTT)|Tt>  ; 

p f r .» : s i s p i > j : - 1 ; p i r t : s i ; 

REP*  A I 

RE  AO  LINE!  TEXT**  .UUFFR  .PIS')  ; 

IF  rtOFERC  1 J- • S • IhtN 


*1  ; 
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fit  GIN 
k :.i  1 5 

IF  ( ( H'JF  ERC  I 0 3 * # •>  ANJ  ( aUFERC  111:'  *1  AND 
I Hl.'t  ERf  12  Js  • •»  ANO  ( CUFt^r  |Jls»  •>> 

rHtN  k:so; 

t:  = i; 

FOG  l:=l  TO  LINE  LENGTH  00 
BEGIN  IF  TEMP  STNTCIJ:*:*  THEN 

uegin  if < (Temp  stftc  i »i  is*u«  > and 

(TEMP  STFI[I«’1=»N*>  AND 
(TEMP  STMTCI*5Js»0»>>  THEN  T:sOI 

ENDS 

eno; 

IF  ((K*Q)  ANO  ( T*3 ) I THEN 
BEGIN 

•HILE  (NOT  EOF (TEXT!))  CO 
BEGIN  BE  * 0 LTNEC TEX T3,bUFER'PTRll S 
IF  BT3FERC  1 3=»t*  IHE N GOTO  430 

ELSE  SAVE  LI NcC  TEXT l,3UFER,PTRI>  S 

ENOS 

ENO 

ELSE  IF ( (KAO)  ANO  (Ttlll  THEN 

SAVE  LlNEtTExTl «BUFE R >P  f R1 ) S 

ENO 

ELSE  BEGIN 

SAVE  LINE! TEXT  I • BUF  ER«PTR1)S 
TEMP- STNT  T SBUFER  t 
ENOS 

6S0:S 

UNTIL  ( EOF ( TEX  T2  ) ) S 
ENOS 


MAIN  ROOT  OF  MAIN  PROGRAM. 


BEGIN 

PASS  IS 

IF  flO  NEW  TTPESXO  THEN  NEEO_MERGE:=TRLE  ELSE  NEED  MERGE SsF ALSE 5 
FIRST  call?=true; 

PRINT  PROC  TREES 

PASS  7(  TExTl*TEXT2.TEXT3M 

PRINT  PROC  TREE! 

IF  NUT ( NEED  MORE  PASS  I T HEN 

BEGIN  MERGE  INTHT(TEXT2.TEXT3tT£XTl) ! GOTO  2000!  ENOS 
PASS  2(TEXT27INTX4«TEXUI! 

PRINT  PROC  TREE! 

IF  NOTLNlEO  MORE  PASS)  THEN 


BE6IN  MERGE  INTXTCINTXA.TEXTI ,TEXT2) ! 

MERGE  IN TXT (TEXT2» TEXT i* TEXT l > J 
GOTO  2000 S 

ENO! 

PASS  2< INTXAtINTXS«TEXT2) S 
PRINT  PROC  TREE! 

IF  NOTCNEED  MORE  PASSI  THEN 
BEGIN 

MERGE  INTxrUNTX5.TEXT2,INTX«JS 
MERGE“INTXT<INTX4,TEXT1 ,TEXT2) ! 

MERGE" IN TXT<  TE X T2, TE XT  3, TEX  III  ! 

GOTO  2000! 

ENOS 

sw:=u 

WHILE! NEED  MORE  PASS l 00 
BEGIN 

MERGE  INTXT(TEXT2.TEXT1*TEXT*»S 
IF  3J=l  THEN 

OCGIN  PASS  2(INTXStTNTX4«TEXT2>S 

sw:=z; 

ENO 

ELSE  UEGIN  PASS  2 ( I NTX4 • IN TXS • TE X T2 > S 

su:=Ti 

ENOS 

ENOS 

IF  SWs  1 THEN  MERGE  INTXTTIMTX5.TEXT2, TEXTII 
ELSE  MERGE"I NT  X T ( I N T XA . TEXT2 . IEX U > 5 
.MERGE  lVTXT«TEXTl,Tr'<TA*TEXT2>; 
MERGE"INTXT(TEXT2, TEXT3. TEXT  I >5 

20oc:T 

ENO. 
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TYPd 

VAR  X 
BEGIN 


P=R£CORO 

x: integer; 

YJREAL 

enu; 

A=AKRaY_11  . .5)  OF  p; 

•j: integer; 

BIARRAY^I  ..  IOJ.  OF  Pi 


i:*i  ; 

J J—5  i 

ENSURE  I=j 

by  i:  = l + i ; 

Ei-5E_BY  i:  = i*a; 

ELSE.BY  Bi22.x:= 

Et-SE_£RRQR; 

WRI  T Ei_N  ( I ) 

ENO. 


i*-  = ; 


B . 2 Translation  of  the  program  in  B.1  by  FT-PASCAL  preprocessor 


TYPE  P=RECQRO 

x:  integer; 
yireal 
end; 

A= ARRAY! 1 . .51  OF  Pi 
TPOOOOOl =RECQRO 

x ; integer  ; 

y :re al 

eno; 

TP000002=  ARRAY!  1 . . 1 0 OF  P ; 

VAR  I , jiinteger; 

ol ARRAY!! .. 101  OF  Pi 
FAUETFLAGS BOOLEAN; 

PROCEDURE  RdOOOOOi; 

VAR 

avooooon  : integer  ; 

dv 0000020  : tpoooooe; 

PROCEDURE  SAOOOOOi;  («  SAVE  *) 

BEGIN 

dvoooooii  : = l ; 

OV000002B  :*o! 

eno  ; 

PROCEDURE  RSOOOOOi;  (*  RESTORE  *) 

BEGIN 

i ;=dvoooooii  ; 

d;=avooooo2o  ; 

eno; 

FUNCTION  VT  000  0 0 1 jboolean;  {*  VALUATION  *) 

BEGIN 

VTOOOOO 1 : -NUT IFAULTFLAO ) AND  ( I-J  )i 

ENO; 

BEGIN 

fauetfeag:  =fal.se;  saoooooi  ; 
i:=n-i ; 

IF  VT  00000 1 THEN  GOTO  1357  (•  EXIT  *> 

EeSE  BEGIN  RSOOOOOi;  FAUL  TFLAG:  = FALSE  • ENO'. 
i :=!+♦; 

IF  VTOOOOO!  THEN  GOTO  1357  I*  EXIT  *) 

EeSE  BEGIN  RSOOOOOi;  FA  UL  T FeAoI = F AeSE • END i 
di  21. x:-i«-5; 

IF  VT  00000 1 THEN  GOTO  1357  I * EXIT  •) 

EeSE  BEGIN 

«KITEeN( 'RECOVERY  PROCEDURE  RdOOoOOl  FAILED*); 

fauetfeag:  strue  ; rsojooou 

end  ; 

i j5?:enj; 

BeG  IN 

I : = I ; 
j:=5; 

Ru  oo  ooo i ; 

WRI TEeNI I ) 

ENO. 
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B , 3 An  FT-PASCAL  program 


TYPE  P=RECOHD 

x: integer; 

VIARRATil. .31  OF  CHAR; 
2 : RE AC 

end; 

VAR  A : ARR  AY^l  . . 10  J.  OF  INTEGER  • 

N. I : IN  TEGEH ; 

REC.ZP; 

FUNCTION  ACC  SORTIbOCcEAN; 

var  is integer; 

BEGIN 

all  scrt:=true; 

FOR  1 S=2  TO  N 00 
BEGIN 

IF  Am  < Ail— 1 1 THEN 
BEGIN 

acc_sort:=facse; 
end  ; 

END  ; 

END ; 


PRQCEDURfc  SOHTi; 

var  i , j «k: integer; 

dcu  1 N 

WR.l  TECNI  • CNTcRED  sort  a*); 
«riteln('a  mas  as  foccoms:*); 

FUR  IS-l  TO  N OO  MR  ITECN(  Ailj.)  ; 

rec . x: -2 ; 

mritecn;  mritecn; 

FOR  I : = 1 TO  N— l DO 
BEGIN 

FOR  TO  N DO 

BEGIN 

IF  Aili.  < AiJl  THEN 
BEG  I N 


END  ; 


END  i 


n :=Aii x; 

Ai I 2 ; - Ai j±i 

a2j2;=n; 


End; 

WR ITECNI • RETURNED  FROM  SORT  l • J 
WRIT Ci_N < • A IS  NOW  AS  follows:') 
FOR  l:  = l TO  N DO  KpRiTEcNtAilii; 

mritecn;  mritecn; 


end  ; 


PROCEDURE  SOR  T2  « 
var  I , j . k; integer ; 

BEGIN 

wri tcln( 'entered  sort  2*); 
mritecn(*a  was  as  foccows:*); 

FOR  l:=l  TO  N DO  WR1TECNI Ailil ; 

rec . z:=j; 

WRI TEEN ; mritecn; 

FOR  Ii=l  TO  N-l  DO 
BEGIN 

FOR  J := l* l TU  N DO 
DEG  I N 

“IF  Aill  > AiJ2  THEN 
BEgIN 

k : = Ail  2 ; 

aii2:*aij2; 

Ai ui ; *k ; 

END  ; 

end  ; 

l"NU*  - continued  - 
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WR  ITELNt  • HETUSi'Jt  J FROM  SORT  2*  ) ; 
WRITELNi' A iS  NOW  AS  FOLLOWS  I • ) J 
FOR  l:=l  TO  N DO  WRITELNi AJI1)  ; 
WRITELN;  WRITELN; 

EMU  ; 

BEGIN 
n:= 10 ; 

WRITELNi * INITIAL  ELEMENTS  OF  A*  ) i 
FOR  li-1  TO  N OO  REAOLNIAH)); 

FOR  Ii=l  TO  N OO  WRITELNi AJT1) ; 
WRITELNi  WRITELNi 

ENSURE  ALL_SORT 

BY  SORT  1 i 

ELSE  oY  S0RT2i 

else_errqr; 

WRI TELNi ‘FINAL  ELMENTS  OF  A*>i 
FOR  II-l  TO  N OU  WRITELNi AJI1) ; 
END. 


B.4  Translation  of  the  program  in  B.3  by  FT-PASCAL  preprocessor 

TYPE  P= RECORD 

x: integer; 

Y : ARRAY!  1.  .3J.  OF  CHAR  i 
z : Real 
ENOi 

TP0  000U2-  ARRAYiKoj,  OF  CHAR 
TP0000  0 1= RECORD 

x : integer  ; 

y jtpoooooe; 

z :real 

end; 

T POOOO C 3=  ARRAYJ1  . . IOJ.  OF  INTeGER 
VAR  Ai  ARRAYX1  . . IOJL  OF  INTEGER  i 
N.  I : INTEGER i 

rec :p; 

faultflag; boole an; 
function  all_sort:buol£an; 
var  i ; integer; 

tJEo  I N 

all  soht:=trgE; 

FOR  i:=2  TO  N 00 
BEGIN 

IF  AiU  < AJI-11  THEN 
BEGIN 

all  sqrt:=false; 
end  ; 

END  ; 

END  ; 


procedure  sorti; 
var  i , j .k: integer; 

BEGIN 

wRI  TELNi  'ENTERED  SORT  !•); 

•RITELNi'A  WAS  AS  FOLLOWS:'); 

FOR  IJ*1  TO  N DO  WRITELNI  Ai.Il)  ; 
rec.x:=2  ; 

wkiteln;  writeln; 
for  i:=i  to  n— i oo 

begin 

fur  j:=i+i  to  n do 

BEGIN 

IF  Aj.ll  < AJJ1  THEN 
BEGIN 

k:=ajii; 
ajii:=ajji; 
ajji:=k; 
end  ; 
end  ; 
end; 

SR  1 TELNi  • RETURNED  FROM  oORT  l')i 
*R  I TELNi  * A IS  NUW  AS  FOLLOWS!'); 

FOR  l:=l  TO  N DU  WRITELNi AJIJ); 

writeen;  writeln; 

end  i _ continued  - 


PROCEDURE  SORT*; 

var  i . j ,k:  integer ; 
begin 

WRI  TELNl  'ENTERED  SORT  Z*  ) i 
WRI TELNl *A  WAS  AS  FOLLOWS:  • ) i 
FOR  ll»X  TO  N DO  WRITELNt  A1IX>  i 
rec.z:»3; 

wRITELNJ  WRITELN; 

FOR  l:*l  TO  N-l  00 
BEGIN 

FOR  j:*X+X  TO  N Du 
BEGIN 

IF  AJ.XJ.  > AiJX  THEN 
BEGIN 

KIsAili.; 

Atxi;-AiJii 

Ai Jli-x : 

END  i 
end; 

END  i 

WRXTELNX ‘RETURNED  FROM  SORT  Z* ) i 
WRIT ELN(  • A IS  NOW  AS  FULLOWs:')* 

FOR  l:=l  TO  N DO  WRlTcLNt  *±l±H 
WRXTELNJ  WRITtLNJ 
End  ; 

PROCEDURE  rboooooi; 

VAR 

dVOOOOO IREC  : 

a vooooo^A  : 

avooooosREC  : 

PROCEDURE  SAOOOOOX: 
acGXN 

bVOOOOOIREc 
dVOOOOO 2A 
o VO 0000 OREL 

end; 

PROCEDURE  RSOOOOOi; 

BEGIN 

REC.X:=BVOOOOO 

a :=avoooo02A  ; 

hec. z:=ovooooo3HEC  ; 

end; 

FUNCTION  VT  000  0 0 X loOOLEAN;  {*  VALIDATION  ♦) 

BEGIN 

VTOOOOO l :=NUT (FAULTFLAG)  AND  ( ALL_SORT  )i 

end; 

BEGIN 

FAULTFLAv.:  =facse;  saoooooi  ; 

SORT1  ; 

IF  VT  00000 1 THEN  GOTO  135/  (*  EXIT  * ) 

ELSE  BEGIN  RSOOOOOi;  FA UL TFcAGi =FAcSE ; END; 

surte; 

IF  VT  000  00 1 THEN  GOTO  1357  < «■  EXIT  *> 

ELSE  BEGIN 

WklTELN(*RECQVERY  PROCEDURE  RB 00  00  0 1 

faultflag: =true;  rsooocoi; 

end; 

i 367: end; 

begin 
n:= i o ; 

WMI TtUN( • INI TImL  ELEMENTS  OF  A*J; 
fur  i :=  i to  n do  readlni Ail ) i ; 

FOR  l:=l  TO  N DO  WRITELNI AiIX> # 

writeln;  writeln; 

Rucocoo i ; 

»VHITtLN(  'FI  NAL  ELMENTS  UF  M*j; 

FOR  15=1  TO  N DO  wRITEcNl AXli)  ; 

END. 


INTEGER  ; 

TP000003 ; 

RE  Ac  ; 

(*  SAVE  *) 

:=rec. x; 

:=a  ; 

:*Rtc. z; 

(*  RESTURc.  *> 

irec  ; 
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FAILED*  ) 


B. 5 Input  data  for  the  program  In  B.3 


00100 

9 

00200 

1 

00300 

8 

0 0400 

2 

00500 

7 

00600 

3 

00700 

6 

00800 

4 

C0900 

S 

01000 

9 

B.6  Result  of  the  execution  of  the  program  in  B.4  with  the  data  in  B.5 

After  S0RT1  fails,  S0RT2  succeeds  in  producing  acceptable  result. 


INITIAL  ELEMENTS  UF  A 
9 

1 

a 

2 
7 

3 
6 

4 

5 
9 


ENTEREO  SORT  1 
A WAS  AS  follows: 

9 

1 

8 

2 

7 

3 
6 

4 

5 
9 


RETURNED  FROM  SORT  1 
A IS  NOW  AS  follows: 
9 
9 
8 
7 
6 
5 
4 
3 
2 
1 


ENTEREO  SORT  2 
A WAS  AS  follows: 

9 

1 
8 

2 
7 

3 
6 

4 

5 
9 


RETURNED  from  SORT  2 
A IS  NOW  AS  FULLGwS: 

1 

2 

3 

4 

5 

6 
7 
6 
9 
9 


FINAL  ELMENTS  OF  A 

1 

2 

3 

4 

5 

o 

7 

8 
9 
9 
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Part  III 


PROGRAMMER-TRANSPARENT  COORDINATION 
OF  RECOVERING  PARALLEL  PROCESSES 


K.  H.  Kim 


PRQGRAMMER-IRAMSPABENT  COORDINATION  OF  RECOVERING  PARALLEL  PROCESSES 


by  K.  H.  Kim 


ABSTRACT : A new  approach  to  coordination  of  cooperating  parallel 

processes,  each  capable  of  error  detection,  rollback,  and  retry,  is 
presented.  Error  detection,  rollback,  and  retry  in  a proccess  are 
specified  by  a well-structured  language  construct  called  recovery 
block.  Coordination  of  processes  is  needed  to  prevent  a disastrous 
avalanche  of  process  rollbacks.  In  contrast  to  the  previously  studied 
approaches  that  require  the  program  designer  to  coordinate  the 
recovery  block  structures  of  interacting  processes,  the  new  approach 
relieves  the  program  designer  of  that  burden.  It  instead  relies  upon 
an  intelligent  processor  system  (that  runs  processes)  capable  of 
establishing  and  discarding  recovery  points  of  interacting  processes 
in  a well  coordinated  manner  such  that  (1)  a process  never  makes  two 
consecutive  rollbacks  without  making  a retry  between  the  two,  and  (2) 
every  process  rollback  becomes  a minimum-distance  rollback.  Following 
the  discussion  of  the  underlying  philosophy  of  the  new  approach,  basic 
rules  of  reducing  storage  and  time  overhead  in  such  a processor  system 
are  discussed.  For  specific  illustration,  systems  in  which  processes 
communicate  through  monitors,  are  considered  and  then  an  intelligent 
processor  system  equipped  with  new  monitor  mechanizations  termed 
f ault-tolerar.t  monitors  and  new  process  stores,  termed  extended 
recovery  caches  is  developed. 


Index  Terms:  rollback  propagation,  process  interaction,  programmer- 
transparent  coordination,  recovery  block,  fault-tolerant  monitor, 
extended  recovery  cache. 


i . introduction 

A a a pragmatic  supplement  to  other  widely  practiced  approaches  to 
obtaining  reliable  real-time  software,  incorporation  of  run-time  error 
detection  and  recovery  capabilities  into  large-scale  software  is 
becoming  an  increasingly  common  practice  [HI ,K1 ,M1 ,R1 ,R2,W1 ,Y1 ,Y2] . To 
successfully  exploit  the  potential  of  this  approach,  it  is  essential 
that  program  redundancy  (specifying  error  detection  and  recovery 
functions)  be  embedded  within  the  program  in  a well-structured  form  so 
that  the  clarity  of  the  overall  program  is  not  degraded  [D1 ,H3»P1 »R1 ] • 
A language  construct  called  recovery  block  (RB)  or  fault-tolerant 
block  was  introduced  by  Horning  et  al  to  support  structured 
incorporation  of  redundancy  into  a program  [ H 3 3 - It  has  the  following 

syntactic  structure:  ensure  V by  01  eise-by  02  else-by  else-by 

0n  else-error,  where  V denotes  the  validation  test.  01  the  primary 

Pb.lect  block,  and  0k  (2ikin)  the  alternate object  fclflgfca- 

Readers  familiar  with  the  semantics  o-f  the  RB  and  with  the  efficient 
storage  scheme  called  recovery  cache  [ A 1 , H3 ] supporting  execution  of 
RBs,  may  skip  the  next  four  paragraphs. 

All  the  object  blocks  in  an  RB  specify  computations  aimed  at 
producing  the  same  or  approximately  the  same  result.  A process 
executes  the  validation  test  V on  exit  from  an  object  block  to  confirm 
that  the  result  of  the  object  block  execution  is  acceptable.  If  it  is 
acceptable,  the  process  exits  from  the  RB.  If  it  is  not,  the  process 
enters  the  next  alternate  object  block.  Also,  the  process  enters  the 
next  alternate  object  block  if  the  underlying  processor  system  detects 
an  error  (e.g.,  divide-by-zero)  while  the  process  is  inside  an  object 
block . 

Before  an  alternate  object  block  is  entered,  the  process  state  is 
restored  to  the  state  that  existed  Just  before  entry  to  the  primary 
object  block.  That  is,  the  process  rolls  back  to  the  recovery  point 
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(RP)  established  on  entry  to  the  RB  [A1,C1,H3].  Each  variable  that 
was  assigned  a new  value  by  the  rejected  execution  is  restored  to  its 
original  value.  The  underlying  processor  system  automatically 
performs  this  "assignment  reversal".  To  enable  this,  the  first 
assignment  to  a non-local  variable  v during  execution  of  an  object 
block  is  preceded  by  the  recording  of  the  origihal  value  of  v,  denoted 
by  PRIOR(v),  in  the  recovery  cache.  Actually  PRIOR(v)  may  also  be 
needed  by  the  validation  test  of  the  RB.  These  (first)  assignment 
records  need  to  be  kept  until  the  RB  is  successfully  exited.  When  an 
RB  is  exited,  the  RP  established  on  entry  to  the  RB  may  be  discarded. 

For'  example,  consider  a program  in  Figure  la.  Figure  1b  shows  a 
snapshot  of  the  recovery  cache  taken  when  primary  object  block  02  1 
is  in  execution.  As  shown,  there  is  a stack,  called  a cache  stack, 
used  for  saving  the  original  values.  Similar  to  the  main  stack,  the 
cache  stack  is  also  divided  into  regions,  one  region  for  each  nested 
RB  in  the  "active"  state  (i.e.,  an  RB  that  has  been  entered  but  not 
exited).  The  top  region  of  the  cache  stack  in  Figure  1b  contains 
names  (representing  logical  addresses)  and  previous  values  of  the  non- 
looal  variables  that  have  been  modified  during  execution  of  the 
current  object  block  02  } (i.e.,  Y2,X1,X2).  Similarly,  the  bottom 
region  of  the  cache  stack  contains  the  previous  value  of  non-local 
variable  XI  which  had  been  modified  by  execution  of  object  01  1 
before  0 2 ^ was  entered.  Figure  1b  also  shows  a flag  field  in  the 
main  stack.  The  flag  indicates  whether  the  original  value  of  the 
associated  variable  has  already  been  saved  since  the  current  object 
block  was  entered.  Thus  the  flags  attached  to  Y2,  XI,  X2  in  the  main 
stack  are  currently  set. 


If  the  result  produced  by  execution  of  0_  ia  rejected  by 
validation  test  V2,  then  the  top  region  C2  of  the  cache  stack  can 
be  used  to  reset  the  main  stack  to  the  state  that  existed  on  entry  to 
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Figure  la  A block-structured  fault-tolerant  program 
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Figure  1b  Recovery  cache  during  execution  of  la 

BB  ^2-  if  it  passes  the  test,  execution  of  F2  is  complete  and 
^2  is  merged  into  Cj  such  that  the  result  will  contain  previous 
values  of  those  variables  that  are  non-local  to  0^  1 and  have  been 
modified  since  0^  ^ was  entered.  Thus  the  result  will  be  a single 
region  containing  (XI, 9)  and  (X2, 2).  Flags  in  the  main  stack  are  also 
adjusted  such  that  only  the  flags  of  XI  and  X2  are  set.  Therefore, 
creation  of  a region  in  the  cache  stack  can  be  viewed  as  the 
establishment  of  a recovery  point  (RP)  and  the  number  of  regions  in 
the  cache  stack  at  any  time  is  equal  to  the  number  of  RPs  existing  at 
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that  time. 


In  a system  of  cooperating  parallel  processes  each  of  which  is 
independently  structured  by  RBs , process  rollback  and  retry  becomes 
greatly  complicated  by  the  possibility  that  rollback  of  a process  X 
may  cause  the  rollback  of  other  processes  which  have  interacted  with 
X[R1,R3,S1].  A process  Y often  has  to  roll  back  into  an  RB  from  which 
it  already  exited  successfully,  because  other  processes  whioh 
interacted  with  Y while  Y was  inside  the  RB,  fall  their  validation 
tests  later  (i.e.,  after  Y exited  the  RB).  This  means  that  a process 
cannot  always  discard  an  RP  on  successful  exit  from  an  RB.  In 
addition,  a disastrous  avalanche  of  rollback  propagations  between 
processes,  called  a domino  effect  [Rl],  could  occur.  To  control  the 
domino  effect,  either  the  program  designer  must  carefully  coordinate 
RPs  (by  coordinating  the  RB  structures)  [ R 1 , R3 3 or  the  processor 
system  that  runs  processes  must  be  designed  to  automatically  manage 
RPs  properly  and  coordinate  the  rollbacks  of  interacting  processes. 

Randell  proposed  a language  construct  called  conversation  to 
aid  the  programmer  in  coordinating  the  RB  structures,  thereby 
supporting  a programmed  (RP)  coordination  approach  [Rl].  In  this 
paper  a programmer-transparent  coordination  approach  relying  upon  an 
intelligent  processor  system  is  explored,  and  some  principles  useful 
for  its  practical  realization  are  discussed.  To  provide  a specific 
example,  an  intelligent  processor  system  that  supports  processes 
communicating  through  monitors  [B1,D2,H2]  is  developed.  The  processor 
system  uses  new  monitor  mechanizations  termed  fault-tolerant 
monitors  and  new  process  stores  termed  extended  recovery  caches. 
(The  fault-tolerant  monitor  is  not  directly  related  to  the  recoverable 
monitor  that  was  developed  in  [SI]  for  a different  purpose.)  Again, 
the  basic  principles  related  to  coordination  of  the  RP  establishments 
and  rollbacks  of  processes  are  valid  independently  of  the  mechanism  by 
which  cooperating  processes  communicate.  A short  review  of  the  basic 
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characteristics  of  a monitor  is  given  in  the  next  paragraph. 

A monitor  consists  of  a shared  data  structure  and  all  the 
operations,  called  monitor  procedures,  that  processes  can  perform  on 
it.  No  more  than  one  monitor  procedure  of  the  same  monitor  may  be  in 
execution  at  any  instant.  A process  X which  has  gained  exclusive 
possession  of  a monitor  and  entered  one  of  the  monitor  procedures,  can 
release  the  monitor  in  two  ways:  one  is  to  exit  from  the  monitor 
procedure  and  the  other  is  to  execute  a "wait(q)B  where  q is  the  name 
of  a queue,  called  a condition  Queue,  into  which  process  X will 
enter  to  sleep.  Without  loss  of  generality,  the  capacity  of  each 
condition  queue  is  assumed  to  be  one.  A process  Y which  enters  a 
monitor  procedure  while  another  process  X is  sleeping  in  condition 
queue  q may  waken  the  process  X by  executing  a "signal( q) " . A process 
can  execute  this  signal  operation  only  as  it  exits  a monitor 
procedure.  A process  checks,  at  various  stages  during  execution  of  a 
monitor  procedure,  to  see  if  the  current  state  of  the  monitor 
satisfies  the  prerequisite  condition  for  the  next  operation;  if  the 
condition  is  not  satisfied,  the  process  will  enter  a condition  queue. 

In  section  2,  basic  problems  arising  in  communication  among 
parallel  fault-tolerant  processes  are  delineated  and  then  the 
( underlying  philosophies  of  the  programmer-transparent  coordination 

approach  are  discussed.  Seotions  3 and  4 develop  a fault-tolerant 
monitor  and  section  5 discusses  a possible  extension.  Proofs  of  two 
lemmas  stated  in  section  3 are  given  in  Appendix  A. 


2 . A programmer-transparent  approach  to  coordination  of  recovering 
parallel  processes 

For  convenience  in  exposition  and  specific  illustration  of  basic 
principles,  the  systems  of  processes  dealt  with  in  the  rest  of  this 
paper  are  assumed  to  have  the  following  characteristics.  For  ease  of 
reference,  the  assumptions,  the  notations,  and  the  definitions  that 
are  developed  in  this  paper  are  numbered  M,  A2 , etc,  N1,  N2,  etc,  and 
D 1 , D2,  etc,  respectively. 

Assumption: 

(A1)  All  the  processes  are  created  during  system  initialization  and, 
once  created,  either  exist  forever  or  terminate  together. 

(A2)  Processes  can  communicate  only  through  monitors,  and  every 
resource  shared  among  processes  must  be  contained  within  a monitor. 
(This  assumption  is  removed  in  section  5.) 

(A3)  There  must  be  a procedure  (known  to  the  underlying  processor 
system)  by  which  the  state  of  a monitor  can  be  recorded  at  any  instant 
and  a procedure  by  which  a recorded  state  can  be  restored  later. 

(AM)  Monitor  procedures  do  not  contain  wait  or  signal  instructions. 
(This  assumption  is  removed  in  section  3-5.) 

Assumption  A2  implies  that  the  only  operations  that  can  be 
performed  on  a shared  resource  are  monitor  procedures.  This 
restrictive  assumption  is  adopted  mainly  to  simplify  the  presentation 
of  the  basic  ideas  of  the  proposed  scheme  and  it  is  removed  in  section 
5.  Assumption  A3  is  trivially  met  if  the  contents  of  shared  variables 
(including  condition  queues)  in  a monitor  completely  represent  the 
state  of  the  monitor,  because  at  any  time  the  contents  can  be  readily 
copied  into  another  memory  region  and  later  reloaded,  if  necessary. 
Recording  and  restoring  a state  of  a special  resource  (e.g.,  disk) 
contained  in  a monitor  may  require  special  procedures  unique  to  the 
resource,  perhaps  supplied  by  the  program  designer.  This  then  would 


be  the  only  burden  put  on  the  program  designer. 


Figure  2a  depicts  a history  of  a system  of  two  fault-tolerant 

t 

processes  communicating  through  a single  monitor.  The  figure  uses  the 

. following  notations. 

' 

Rotation: 

(N 1 ) The  processes  progress  downward. 

fR2)  A bracket  represents  an  RB  execution  (RBE)  and  each  short  wavy 
line  represents  a recovery  point  (RP)  of  a process.  The  bottom  end  of 
a bracket  represents  an  execution  of  the  associated  validation  test. 
<N3>  A shaded  column  represents  the  history  of  the  state  of  a monitor, 
and  a change  in  the  direction  of  shading  represents  a state  change. 
(N4)  A horizontal  line  represents  execution  of  a monitor  procedure.  A 
line  directed  toward  a shaded  column  represents  a monitor  update 
operation  (i.e.,  execution  of  a monitor  procedure  which  only  changes 
" the  state  of  a monitor  without  examining  the  state  at  all),  while  a 

line  directed  toward  a process  from  a shaded  column  represents  a 
monitor  reference  operation  (i.e.,  execution  of  a monitor  procedure 
which  does  not  change  but  examines  the  state  of  a monitor).  In  most 
_ cases  a monitor  procedure  contains  both  reference  and  update 

operations.  Execution  of  such  a procedure  is  treated  as  a monitor 
reference  operation  immediately  followed  by  a monitor  update 

operation . 

Process  A in  Figure  2a  produces  information  at  A. 3 for  other 
processes  and  stores  into  monitor  M.  A little  later  process  B picks 
up  this  information  (or  a part  of  it)  at  B.4.  Process  B passes  its 

validation  test  at  B.5.  If  process  A fails  at  A.p,  then  it  will  roll 

back  to  RP  A.1  and  revoke  the  information  it  sent  out  between  A.1  and 

A.p.  (As  part  of  this  rollback,  process  A must  restore  monitor  M to 

~ the  state  that  existed  prior  to  A. 3.)  Revocation  of  A. 3 should  cause 

process  B to  roll  back  to  an  RP  established  prior  to  B.4,  even  though 
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Figure  2a  A system  history 

B has  already  passed  its  own  validation  test.  A programmed  validation 
test  cannot  detect  all  possible  errors.  Therefore,  if  process  A 
fails,  process  rollback  is  propagated  to  process  B due  to  the 
revocation  of  the  information  sent  out  by  A.  This  type  of  rollback 
propagation  is  called  an  R-propagation  in  this  paper. 

On  the  other  hand,  if  process  B in  Figure  2a  fails  at  B.5  and 

rolls  back  to  RP  B.2,  then  the  question  arises  as  to  whether  process  A 

should  roll  back.  The  Information  received  at  B.4  may  have  caused  the 
failure  of  B.  Therefore,  process  B may  be  suspicious  of  the  integrity 
of  process  A and  ask  A to  roll  back  to  an  RP  p-ior  to  A.p.  This  type 

of  rollback  propagation  is  due  to  the  suspicion  by  process  B and 

called  an  a-pr<?gafiatl<?n - 

When  S-propagations  are  permitted,  an  avalanche  of  rollback 
propagations  may  occur  unless  the  program  designer  takes  great  care  in 
coordinating  the  RB  structures  of  interacting  processes.  For  example, 
if  process  A in  Figure  2b  fails  at  A.p,  then  process  A may  be 
suspicious  of  the  integrity  of  the  information  received  at  A. 22. 
Process  B may  have  supplied  the  information  either  in  full  at  B.21  or 
in  parts  at  B.5,  B.13,  and  B.21.  Some  part  of  the  information  may 
even  have  been  deposited  in  the  monitor  by  process  A itself  at  A.1, 
A. 9 or  A . 1 7 . Upon  receiving  a request  from  process  A to  roll  back  to 
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an  RP  preceding  B.21,  process  B may  in  turn  be  suspicious  of  the 
integrity  of  the  information  received  at  B.18  and  thus  request  process 
A to  roll  back  to  an  RP  preceding  A. 17.  Continuing  this  way,  both 
processes  will  have  to  roll  back  all  the  way  to  their  beginnings  (a 
domino  effect  occurs).  Note  that  when  S-propagations  are  permitted,  a 
process  can  roll  back  to  an  RP  r and  then  continue  to  roll  back  to 
another  RP  without  making  a retry  at  r.  Because  of  this,  S- 
propagations  are  prohibited  in  the  programmer-transparent  coordination 
approach  explored  in  this  paper. 


Figure  2b  A system  history 

Allowing  only  R-propagations  means  that  a process  which  sends  out 
incorrect  information  is  solely  responsible  for  detection  and 
oorrectlon  of  this  error.  Under  this  stategy  a process  oan  discard 
the  RP  established  on  initiation  of  an  RB  on  passing  the  associated 
validation  test  if  the  process  did  not  receive  information  from  other 
processes  but  only  sent  out  information  during  execution  of  the  RB. 
For  example,  process  A in  Figure  2a  which  does  not  know  the  speed  of 
the  progress  of  process  B can  discard  RP  A.1  on  passing  validation 
test  A . p . In  a sense,  process  A gives  a posteriori  accreditation  of 
the  information  sent  out  between  A.1  and  A.p  on  passing  A.p  and  then 
no  other  processes  can  challenge  the  integrity  of  the  information. 
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When  only  R-propagations  are  permitted,  it  is  possible  to  prevent 
a process  from  making  two  consecutive  rollbacks  (without  a retry  after 
the  first  rollback),  by  establishing  RPs  Immediately  before  certain, 
but  not  all,  monitor  reference  operations.  These  RPs  are  in  addition 
to  the  RPs  established  on  initiation  of  RB  executions  (RBEs).  The  RPs 
established  immediately  before  monitor  references  are  called  branch 
RPs . while  the  RPs  established  on  initiation  of  RBEs  are  called  base 
RPs.  Establishment  of  branch  RPs  is  transparent  to  the  program 

designer.  For  example,  process  B in  Figure  2c  established  a branch  RP 
immediately  before  monitor  reference  B.7.  Such  an  RP  will  be  referred 
to  by  the  name  (e.g.,  B.7)  of  the  immediately  following  monitor 

operation  in  the  rest  of  this  paper.  Process  A also  established 
branch  RP  A. 3-  If  process  A fails  validation  test  A.p  and  revokes 
monitor  update  A. 6,  then  process  B rolls  back  to  RP  B.7  and  no  more 
rollback  propagation  will  ensue.  In  this  case,  process  B makes  a 
minimum-distance  rollback.  If  branch  RPs  B.7  and  A. 3 had  not  been 
established,  process  B would  have  rolled  back  to  base  RP  B.1  and 

revoked  monitor  update  B.2,  which  in  turn  would  have  caused  process  A 
to  roll  oack  to  an  RP  preceding  A. 3;  process  A would  thus  have  made 
two  consecutive  rollbacks,  first  to  RP  A. 5 and  then  to  the  RP 

preceding  A. 3,  without  a retry  from  A. 5. 


Process  Monitor  Process 


Figure  2c  Establishment  of  two  branch  RPs  A. 3 and  B.7 


Figure  2c  also  reveals  an  additional  aspect  of  monitor  update 
accredidation . Before  process  A executes  validation  test  A.p,  process 
B has  passed  validation  test  B.11  and  thus  has  given  a posteriori 
accreditation  of  monitor  update  B.10.  Note  that  this  accreditation  is 
indirectly  voided  when  process  A fails  at  A.p  and  causes  process  B to 
roll  back  to  B.7,  although  the  accreditation  issued  is  not  directly 
challenged . 


In  short,  the  essence  of  the  programmer-transparent  coordination 
approach  is  to  prohibit  S-propagations  and  to  establish  certain  branch 
RPs  in  addition  to  base  RPs,  thereby  ensuring  that  a process  never 
makes  two  consecutive  rollbacks.  A process  need  also  save  the  states 
of  a monitor  immediately  before  certain,  but  not  all,  monitor  update 
operations  in  order  to  be  able  to  restore  the  monitor  if  the  updates 
are  revoked  later.  The  approach  is  practical  only  if  at  all  times  the 
number  of  RPs  and  the  number  of  previous  states  of  monitors  that  each 
process  needs  to  maintain  is  manageable.  All  the  management 
functions,  including  maintenance  of  RPs,  restoration  of  monitors,  and 
coordination  of  process  rollbacks,  must  be  automatically  handled  by 
the  underlying  processor  system.  Basic  principles  that  can  be 
gainfully  exploited  in  practical  implementation  of  the  programmer- 
transparent  coordination  approach  are  discussed  in  the  next  section. 


3 . Fault-tolerant  monitor  and  extended  recovery  caches  In  systems 
using  one  monitor 

It  was  mentioned  in  the  preceding  section  that  the  feasibility  of 
the  programmer-transparent  coordination  approach  is  largely  dependent 
upon  the  reduction  of  the  time  and  storage  overhead  required  by  an 
intelligent  processor  system.  Two  major  sources  of  overhead  are  in 
creation  and  discard  of  (1)  RPs  and  (2)  records  of  previous  states  of 
monitors.  Basic  principles  useful  for  reduction  of  this  overhead  are 
now  discussed.  To  simplify  the  presentation,  this  section  deals  only 
with  the  systems  using  one  monitor.  Figure  3 depicts  such  a system. 
Furthermore,  most  illustrations  are  made  with  simple  two-process 
systems . 


Figure  3 A system  of  processes  communicating  through  one  monitor 

3 - 1 Minimal  recovery  point  (RP)  establishment 

To  get  an  intuitive  idea,  consider  Figure  4a.  Process  B 
established  a branch  RP  at  the  beginning  of  monitor  reference  B.4 
since  the  information  existing  then  in  the  monitor  was  subject  to 
possible  future  revocation  (due  to  the  possible  failure  of  the  RBE 
initiated  at  A.1).  However,  it  was  not  necessary  for  process  B to 
establish  additional  RPs  at  monitor  references  between  B.6  and  B.J. 
This  is  because  ar.y  information  picked  up  from  M between  B.4  and  B.J 
is  revoked  only  when  process  A rolls  back  to  A.1,  and  thus  the 
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references  (made  between  B.6  and  B.J)  are  voided  together  with 
reference  B.4.  Therefore,  an  on-going  RBE  of  a process  X causes 
another  process  Y to  create  at  most  one  branch  RP,  and  process  Y must 
maintain  the  RP  at  least  until  the  RBE  (of  X)  deceases.  If  process  A 
in  Figure  4a  passes  validation  test  A.p,  then  RP  B.4  may  be  discarded. 
(Communication  of  validation  results  and  other  notices  among  processes 
is  discussed  in  section  3-3-1  •)  Base  RP  B.2  can  not  be  discarded  even 
after  validation  test  B.k  succeeds  as  long  as  branch  RP  B.4  remains. 
This  is  because  once  process  B rolls  back  to  branch  RP  B.4,  it  can 
fail  at  B.k  in  which  case  it  needs  to  roll  back  to  base  RP  B.2.  In  a 
sense,  the  RBE  that  was  initiated  at  B.2  is  not  completely  validated 
even  after  B.k  until  the  RBE  that  was  initiated  at  A.1  is  completely 
validated  at  A.p  and  branch  RP  B.4  is  discarded. 


Figure  4a  A system  history 

So  that  the  conditions  for  establishment  and  discard  of  RPs  can 
be  stated  precicely,  the  following  notations  and  terms  are  introduced. 

itotation : (N5)  An  RBE  is  represented  by  [a:]  or  [:b],  where  a and 

b are  the  starting  and  the  ending  execution  points,  respectively,  of 
the  RBE.  For  example,  [B.2:]  and  [:B.k]  in  Figure  4a  represent  the 
same  RBE. 
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(D1)  When  a monitor  M is  updated  by  a process  X during  an  RBE  [X.a:], 
the  RBE  [X.a:]  becomes  a potential  recaller  of  monitor  M and  holds 
that  right  until  [X.a:]  deceases.  For  example,  [A.1:]  in  Figure  4a 
is  a potential  recaller  of  M from  A. 3 to  A.p.  Monitor  M is  said  to  be 


rollback- chained  or  R-chalned  to  the  base  RP  established  at  the 
starting  point  X.a  of  RBE  [X.a:]. 

(02)  When  a monitor  M has  no  potential  recallers,  it  is  said  to  be 
rollback-free. 

(03)  If  a process  Y references  a monitor  M which  is  R-chained  to  base 

RP  X.a,  then  process  Y becomes  flr.cha.lnsd  tLg  BE X.a  through  monitor 

U,  and  thus  RBE  [X.a:]  becomes  a potential  recaller  of  process  Y. 

IT  process  Y becomes  R-chained  to  RP  X.a  during  an  RBE  [Y.e:],  then 
RBE  [Y.c:]  is  said  to  be  R-chained  to  RP  X.a.  Thus  RBE  [X.a:]  is  a 
aatential .recaller  of  RBE  rY.c:1. 

(04)  An  RBE  of  a process  X ,is  a potential  recaller  of  process  X 

Uaslf. 

In  Figure  4b  RBE  [A. 2:]  in  becomes  a potential  recaller  of  M at 
its  first  update  (A. 3)  of  M,  and  RBE  [B.1:]  of  process  B becomes  R- 
chalned  to  base  RP  A. 2 at  the  first  reference  (B.4)  to  M after  M 
became  R-chained  to  the  RP  A. 2.  Monitor  M has  two  potential  recallers 
[A. 2:]  and  [B.1:]  immediately  after  B.5.  By  definition  04,  RBE 
[B.1:]  is  a potential  recaller  of  process  B between  B.1  and  B.p. 


(05)  The  set  of  all  the  potential  recallers  of  a process  X (or  a 
monitor  M)  at  a given  time  t is  called  the  potential  recaller  set 
(PRS)  of  X (or  M)  at  t,  and  is  denoted  by  PRS(X.t)  (or  PRS(M.t)). 
The  second  argument  t may  be  omitted  if  there  is  no  ambiguity. 
Similarly,  the  PRS  of  an  RBE  [X.a:]  at  t is  defined  and  is  denoted  by 
PRS([X.a:],t),  where  t may  be  omitted  if  there  is  no  ambiguity. 

(D6)  The  potential  recaller  closure  (PP»1  of  an  RBE  [X.a:]  at  a 
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Procafs  A Monitor  M Procats  B 


Figure  4b  A system  history 

> 

given  instant,  denoted  by  PR*([X.a:]),  is  a set  of  RBEs  defined  as 
follows:  every  potential  recaller  of  RBE  [X.a:]  is  a member  of 
PR*([X.a:]);  if  an  RBE  e is  a member  of  PR*([X.a:]),  then  every 
potential  recaller  of ' e is  also  a member  of  PR* ( [X. a: J ) . 

(D7)  An  RBE  [Z.e:]  which  is  not  a potential  recaller  of  RBE  [X.a:] 

but  a member  of  PR*([X.a:]),  is  called  an  indirect  potential 
r.ecaller  of  RBE  [X.a:]. 

(D8)  The  set  of  all  the  indirect  potential  recallers  of  an  RBE  [X.a:] 
is  called  the  indirect  .potential .recaller  set  (IPRS)  of  RBE  [X.a:] 
and  is  denoted  by  IPRS( [X . a : ] ) . 

The  PRS  of  an  RBE  [X.a:]  can  be  a proper  subset  of  PR*([X.a:]) 
because  PR* ([X.a:])  may  increase  after  process  X passes  the  validation 
test  of  RBE  [X.a:]  (and  thus  PRS([X.a:])  is  fixed).  For  example, 

process  C in  Figure  4c  already  passed  the  validation  test  of  RBE 
[ C . 1 : ] at  C.6.  Thus  PRS([C.1:])  was  fixed  at  C-6  and  includes  on- 
going RBE  [B.2:]  of  process  B.  When  RBE  [B.2:]  became  R-chained  to 

RP  A. 5 of  another  process  A later  at  B.9,  RBE  [A. 5:]  became  a member 

of  PR*([C.1:])  but  it  is  not  a potential  recaller  of  [ C . 1 : ] - 

definition: 

(D9)  An  RBE  [:X.b]  is  said  to  be  partially  validated  if  validation 
test  X.b  has  been  successful  but  there  remain  potential  recallers  of 
[:X.b]  (i.e.,  there  are  RBEs  of  other  processes  which  became  potential 
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A M B C 


Figure  4c  An  indirect  potential  recaller  [A. 5:1  of  RBE  [C.1:] 

recallers  of  process  X during  [:X.b]  and  have  not  deceased). 

(DIO)  An  RBE  [:X.b]  is  completely  validated  if  (1)  validation  test 
X.b  has  been  successful  and  (2)  either  PR*([:X.b])  is  empty  or  every 
member  of  PR*([:X.b])  has  been  completed  with  passing  of  the 
associated  validation  test. 

An  informal  definition  of  "complete  validation"  is  validation  of 
every  aspect  of  an  RBE.  Therefore,  once  an  RBE  [X.a:]  is  completely 
validated,  there  will  never  be  any  need  for  process  X to  roll  back  to 
RP  X.a.  In  the  case  of  Figure  4b,  complete  validation  of  RBE  [A. 2:] 
or  [B.t:]  consists  of  validation  tests  A. 7 and  B.p.  RBE  [A. 2:]  is 
first  partially  validated  at  A. 7.  Then  RBE  [A. 2:]  becomes  completely 
validated  together  with  [B.1:]  at  B.p  when  every  member  of 

PR* (C A .2 : ] ) s PR*([B.1:])  = { [ A. 2 : ] , [ B . 1 : ] } has  obtained  the  partially 
validated  status.  On  the  other  hand,  RBE  [C.1:]  in  Figure  4c  is  not 
completely  validated  even  when  validation  test  B.p  succeeds,  because 
PR*([C.1:])  contains  on-going  RBE  [A. 5:].  Figure  5 depicts  various 
states  that  a newly  initiated  RBE  may  go  through. 

The  rule  for  maintaining  the  PRSs  of  processes  and  of  the  monitor 
stems  from  definitions  D1  - D5,  and  is  stated  below. 
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R8£  initiation 


Figure  5 Life  cycle  of  an  RBE 

BJiLa:  (Rl)  "PRS  management" 

(R1.1)  RBE  initiation:  when  a process  X is  about  to  Initiate  an  RBE 
at  X.a,  PRS(X)  is  updated  to  PRS(X)  U {[X.a:]}  where  U is  a set-union 
operator . 

(R1.2)  Monitor  update:  when  a process  X is  about  to  update  a monitor 
M,  PRS(M)  is  updated  to  PRS(M)  U PRS(X). 

C R 1 - 3 ) Monitor  reference:  when  a process  X is  about  to  reference  a 
monitor  M,  PRS(X)  is  updated  to  PRS(X)  U PRS(M). 

(R1.4)  Complete  validation  of  an  RBE:  If  an  RBE  [X.a:]  has  been 
completely  validated,  [X.a:]  is  removed  from  the  PRSs  of  processes 
and  from  the  PRS  of  the  monitor. 

(P.1.5)  Discard  of  an  RBE:  If  an  RBE  [:X.b]  is  discarded  due  to  a 

failure  at  or  before  X.b,  [:X.b]  is  removed  from  the  PRSs  of  processes 
and  from  the  PRS  of  the  monitor. 
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By  using  the  PRSs  of  processes  and  the  monitor,  a rule  for 


correctly  establishing  RPs  can  be  stated  as  follows. 


Rule:  ( R2 ) "RP  establishment  and  discard":  when  the  PRS  of 

process  X,  PRS(X),  is  expanded  by  incorporating  a set  E of  new 


members,  a new  RP  is  established  by  X.  E is  called  the  PRS  of  the 
££..  The  RP  may  be  discarded  only  when  all  the  members  of  its  PRS  E 
have  been  removed  from  PRS(X). 


Note  that  the  PRSs  of  RPs  are  mutually  disjoint  and  that  the  PRS 


. at  that  time.  In  addition, 


during  C : X . b 1 and  have  remained.  As  an  illustration  of  the  above 
rule,  PRS(A)  in  Figure  4a  is  expanded  at  A.1  and  thus  a base  RP  is 
established  at  A.1.  Similarly,  PRS(B)  is  expanded  at  B.4  and  thus  a 
branch  RP  is  established  at  B.4.  When  validation  test  A.p  succeeds, 
RBE  [A.1:]  is  completely  validated  and  thus  is  removed  from  PRS(A), 
PRS(B),  and  PRS(M).  Since  the  PRSs  of  both  RPs  A.1  and  B.4  are  now 
empty,  the  two  RPs  are  discarded.  RBE  [B.2:]  has  jalso  been 
completely  validated  and  RP  B.2  is  discarded.  In  the  case  of  Figure 
2c,  RP  B.9  ia  discarded  when  validation  test  B.11  succeeds  but  RPs 
B.7,  B . 1 , A. 5,  and  A. 3 are  all  discarded  when  validation  test  A.p 
succeeds . 


The  above  PRS  management  rule  R1  is  not  complete  yet.  See  Figure 
6a.  Under  the  present  rule  process  B establishes  an  RP  at  B.4. 
Therefore,  if  process  A fails  at  A.p  and  rolls  back  to  A.1,  then 
process  B rolls  back  to  B.4  and  resumes  execution.  However,  the 
information  produced  at  B.3  has  been  lost  and  thus  the  information 
process  B acquires  at  B.4  after  resuming  execution  may  be  incorrect. 
A logical  solution  to  this  problem  is  to  establish  an  RP  at  (the 
beginning  of)  B.3  Instead  of  B.4.  The  problem  then  is  how  to 
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recognize  the  need  for  RP  establishment  at  a monitor  update  such  as 
B.3.  Note  that  PRS(M)  contains  an  RBE  which  is  not  contained  in 
PRS(B)  at  B.3.  Therefore  a solution  is  to  modify  the  rule  R1  as 
follows . 

Modified  rule:  (R1.2)  Monitor  update:  when  a process  X is  about  to 
update  a montor  M,  both  PRS(X)  and  PRS(M)  are  updated  to  PRS(X)  U 
PRS(M) . 


Process  A Monitor  M Process  B 


Figure  6a  Incorrect  establishment  of  a branch  RP 

In  the  case  of  Figure  6a,  PRS(B)  is  a null  set  before  B.3  but  it 
becomes  {[A.1:]}  at  the  beginning  of  B.3.  Therefore,  by  the  RP 
management  rule  R2,  an  RP  is  established  at  the  beginning  of  B.3. 
Since  PRS(B)  does  not  change  at  B.4,  no  RP  is  established  there. 

The  following  statement  can  be  made  about  this  RP  management 

rule. 

Lftnna. • (LI)  Under  rule  R2  processes  maintain  the  minimum  number  of 
RPs  required  to  enable  every  rollback  to  be  made  to  the  most  recent 
valid  execution  point,  provided  RBEs  can  be  removed  from  the  PRS3  as 
soon  as  they  are  completely  validated  or  discarded.  (Proof  in 
Appendix  A) 


< 
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An  example  of  an  RP  having  more  than  one  potential  recaller  is  RP 
B-7  in  Figure  6b  which  has  two  potential  recallers,  [A.1:]  and 
[A. 5:],  until  A. 10.  This  means  that  RP  B.7  must  remain  intact  until 
A. 11  (even  after  [A. 5:]  Is  successfully  completed  at  A. 10). 
Therefore,  the  number  of  RPs  maintained  by  a process  X is  always  less 
than  or  equal  to  the  cardinality  of  PRS(X).  PRS(X)  is  of  course  a 
subset  of  on-going  or  partially  validated  RBEs  of  the  processes  in  the 
system. 


Proceis  A Monitor  M Process  B 


Figure  6b  A branch  RP  (B.7)  having  two  potential  recallers 

3-2  Reduction  of  the  number  of  RPs 

Although  no  redundant  RPs  are  maintained  under  the  RP  management 
rule  R2  given  in  the  preceding  section,  the  number  of  RPs  maintained 
at  one  time  could,  in  many  cases,  exceed  the  tolerable  limit  (imposed 
mainly  by  storage  space  available).  For  example,  consider  Figure  7a 
which  looks  similar  to  but  possesses  the  opposite  characteristics  of 
Figure  2b  from  the  RP  management  point  of  view.  (Every  RBE  in  Figure 
2b  is  completely  validated  as  its  associated  validation  test 
succeeds.)  Each  time  a validation  test  succeeds,  it  results  only  in  a 
partial  validation  because  there  is  a potential  recaller  which  is 
active  at  that  time.  Therefore,  no  RPs  could  have  been  discarded  by 
A.p.  If  process  A passes  validation  test  A.p,  then  all  the  RPs 
(except  B.25)  can  be  discarded. 
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Proeaai  A Monitor  M Process  3 


Figure  7a  A system  history 

In  order  to  avoid  intolerable  accumulation  of  partially  validated 
RBEs  and  associated  RPs  in  a process  X,  process  X can  safely  remove 
old  RPs  which  have  low  probability  of  being  used.  For  example,  RP  B.1 
or  B-7  in  Figure  7a  is  considered  to  have  a comparatively  low 
probability  of  being  used  because  it  can  be  used  only  when  all  the 
subsequent  RBEs  (by  both  processes  A and  B)  that  have  been  partially 
validated  were  actually  wrong.  Therefore,  process  B may  remove  B.7 
and  thus  sacrifice  the  capability  of  rolling  back  to  the  most  recent 
valid  execution  point  B-7  in  the  ease  where  RBE  [ A . 5 : ] is  discarded. 
Process  B must  retain  base  RP  B.1  after  discarding  RP  B.7.  If  RBE 
[A.5:]  is  later  completely  validated,  then  RP  B.1  can  also  be 
discarded.  If  [A. 5: 3 is  discarded,  then  process  B can  immediately 
declare  that  RBE  [B.1: 3 has  failed  and  then  roll  back  to  B.1  as  if  it 
had  made  a retry  from  B.7  and  failed  the  validation  test  of  [B.1:3. 
This  will  cause  process  A to  roll  back  to  A. 3.  Therefore,  process  B 
as  well  as  process  A can  still  be  recovered  as  long  as  it  maintains 
the  oldest  RP,  although  it  sacrificed  the  ability  to  make  a minimum- 
distance  rollback  every  time.  In  other  words,  a process  can  trade 
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increase  of  rollback  distance  (in  case  of  less  probable  rollbacks)  for 
reduction  of  RPs. 


. 

t 

f i 

Definition:  (Dll)  A base  or  branch  RP  r is  said  to  be  supported 

j a base  RP  q if  r was  established  during  RBE  [q:].  For  example,  RP 

B.7  in  Figure  7a  is  supported  by  RP  B.l.  Also  RP  A. 5 in  Figure  6b  is 
supported  by  RP1  A . 1 . 

A two-part  rule  for  safe  reduction  of  RPs  is  now  given. 

JllllS.:  (R3)  "RP  reduction" 

(R3-1)  A branch  RP  r can  be  removed  if  (1)  its  immediately  preceding 
RP  q is  a base  RP  and  (2)  r is  supported  by  q.  Once  removed,  r is 
called  a defunct  branch  of  q.  If  process  X is  required  to  roll  back 
to  defunct  branch  r,  it  will  immediately  notify  other  processes  and 
the  monitor  that  RBE  C q : ] has  failed  and  then  it  will  roll  back  to  q. 
(R3-2)  A base  RP  r can  be  removed  if  (1)  its  immediately  preceding  RP 
q is  another  base  RP  and  (2)  there  are  no  remaining  RPs  supported  by 
r.  Once  removed,  r and  its  defunct  branches  become  defunct  branches 
of  q.  When  process  X removes  r,  it  notifies  other  processes  and  the 
monitor  that  the  role  of  RBE  [r:]  as  a potential  recaller  is  taken 
over  by  RBE  [q:].  If  process  X is  required  to  roll  back  to  defunct 
branch  r,  it  will  immediately  communicate  that  RBE  lq:]  has  failed 
and  then  it  will  roll  back  to  q. 


The  immediate  effect  of  removing  a branch  RP  is  local  to  the 
process.  However,  the  effect  of  removing  a base  RP  may  propagate  to 
other  processes.  For  example,  suppose  that  process  B in  Figure  7a 
first  removed  branch  RPs  B.7  and  B.15  and  then  removed  base  RP  B.9. 
How  whenever  process  B is  required  to  roll  back  to  B.9,  it  has  to  roll 
back  to  B.l.  This  means  that  process  A will  never  roll  back  to  A . 1 1 ; 
Instead  it  will  be  required  to  roll  back  to  A. 3.  In  other  words,  the 
role  of  [B.9:]  as  a potential  recaller  has  been  taken  over  by  [B.l:]. 
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Therefore,  If  a base  RP  X.J  has  been  made  a defunct  branch  of  another 
base  RP  X.i,  RBE  [X.j:]  must  be  removed  from  the  PRSs  of  processes 
and  of  the  monitor.  Removal  of  [X.J:]  from  the  PRS  of  a process  Y 
may  enable  discard  of  RPs  in  the  process  Y.  Figure  7b  shows  the 
result  after  process  B removes  the  five  RPs  B.7,  B.15,  B.9,  B.23  and 
B.17  in  sequence.  Again  RPs  A. 3,  A. 21  and  B.1  can  be  discarded  when 
validation  test  A.p  succeeds. 


Proc***  A 


Proem  B 


defunct 

brunch 


Figure  7b  Result  after  process  B removes  five  RPs  from  7a 


Implementation  of  the  rules  for  RP  establishment,  discard,  and 
reduction  is  discussed  in  the  next  section. 


3.3  Implementation  of  the  RP  management  rule 


3.3-1  Store  structures.  PRS  maintenance,  and  mailbox  operations 


Figure  8a  depicts  store  structures  in  an  abstract  form.  Each 
process  or  monitor  owns  an  independent  store  space.  A process  store 
(PS)  which  is  an  extended  recovery  cache,  consists  of  a main  stack, 
a cache  stpre,  and  a table  PRST  containing  the  PRS  of  the  process. 

As  in  the  recovery  cache  shown  in  Figure  1b,  a main  stack  provides 
space  for  local  variables  of  internal  procedures  and  monitor 
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procedures  that  have  been  entered  by  a process  but  not  exited.  A 
cache  store,  which  is  an  extension  of  a cache  stack  (shown  in  Figure 
1b),  contains  information  necessary  for  validation  and  rollback. 
Although  the  PRS  of  a process  as  a whole  is  contained  in  the  table 
PRST , the  PRS  of  each  RP  is  recorded  in  a cache  store  (detailed  in 
section  3.3.2).  Thus  information  on  the  PRS  of  a process  as  a whole 
can  also  be  assembled  from  the  PRS  records  of  RPs.  Table  PRST  within 
a process  store  is  redundant  in  a sense  but  its  use  is  motivated  by  an 
efficiency  consideration.  Updating  table  PRST  always  accompanies 
updating  some  of  the  PRS  records  of  RPs  kept  in  a cache  store.  Note 
that  table  PRST  and  PRS  records  of  RPs  are  transparent  to  the  program 
designer;  the  processor  system  automatically  provides  and  manages 
these. 


Figure  8a  Process  store  and  monitor  store 

A monitor  store  (MS)  consists  of  a shared  data  store,  a table 
EBSI . and  mailboxes  which  are  queues  of  messages  addressed  to 
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processes.  Also  attached  to  each  entry  (i.e.,  potential  recaller 

name)  In  table  PRST(M)  of  monitor  M la  a queue  of  RP  names. 

i 

I I 

i • 

b:  notation; 

(N6)  The  process  store  of  process  X Is  denoted  by  PS(X)  and  the 
monitor  store  of  monitor  M Is  denoted  by  MS(M).  The  mailbox  of 
process  X within  MS(M)  Is  denoted  by  MB(X,M),  where  the  second 
argument  M may  be  omitted  if  there  is  no  ambiguity. 

(N7)  A queue  of  RP  names  attached  to  the  entry  for  RBE  [X.a:]  in 
table  PRST(M)  is  denoted  by  RPQ(M, [X . a; ] ) . 


Again  table  PRST  and  mailboxes  in  a monitor  store  are  transparent  to 
the  program  designer.  These  resources  are  used  as  follows. 

When  a potential  recaller  [X.a:]  of  monitor  M becomes  a new 
potential  recaller  of  a process  Y,  process  Y establishes  an  RP  and 
inserts  the  name  of  the  RP  into  RPQ(M, [X . a: ] ) . When  RBE  [X.a:]  is 
either  completely  validated  or  discarded,  process  X accesses  table 
PRST(M)  (after  obtaining  exclusive  possession  of  M,  of  course).  For 
every  RP  name  r in  RPQ(M,[X.a: ] ) , process  X puts  a message  in  the 
mailbox  for  the  process  Y that  established  RP  r.  It  then  deletes 
[X.a:]  (as  well  as  RPQ(M, [X . a: ] ) ) from  table  PRST(M)  and  releases  M. 
The  message  is  either  a complete  validation  notice  "[X.a:] 
associated  with  r has  been  completely  \'alidated"  or  a rollback 
notice  "[X.a:]  has  failed,  so  roll  back  to  r"  depending  upon  how  RBE 
[X.a:]  has  deceased.  If  RBE  [X.a:]  has  been  discarded,  process  X 
also  removes  the  RBEs  and  the  branch  RPs  of  process  Y that  were 
initiated  or  established  later  than  r,  from  table  PRST(M).  (This 
implies  that  RBEs  and  RP  names  must  be  assigned  such  that  they  provide 
the  ages  of  the  RBEs  and  RPs.)  Then  later  when  process  Y gains  the 
monitor  for  some  reason  (e.g.,  update,  reference,  notification  to  the 
monitor  of  the  decease  of  an  RBE,  etc),  it  checks  the  mailbox  first. 
If  there  is  a message,  process  Y picks  it  up,  releases  the  monitor, 
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and  interprets  the  message  before  regaining  the  monitor  to  take  the 
intended  action.  When  process  Y regains  the  monitor,  it  again  checks 
the  mailbox  first.  Therefore,  monitor  acquisition  and  mall  check 


r 


form  a single  inseparable  operation. 

Note  that  there  is  a variable  time  gap  between  the  decease  of  an 
RBE  and  the  receipt  of  its  notice  by  other  processes  because  each 
process  checks  a mailbox  at  its  own  pace  rather  than  being  interrupted 
when  mail  is  deposited.  This  means  that  a process  could  keep  a 
defunct  RBE  in  its  table  PRST  for  some  time,  but  this  cost  seems  well 
Justified,  considering  the  complexity  of  an  entirely  interrupt-driven 
implementation . 

However,  a situation  may  arise  where  a process  X never  accesses  a 
monitor  M after  a rollback  notice  is  put  in  the  mailbox  MB(X,M). 
Therefore,  it  is  not  possible  to  completely  do  away  with  an  interrupt. 
A process  interrupt  used  to  inform  a process  of  the  existence  of 
messages  in  a mailbox  can  be  implemented  in  various  ways.  In  this 
paper,  it  is  simply  assumed  that  a system  contains  a programmer- 
transparent  "watchdog"  process  which  periodically  examines  all  the 
mailboxes  and  can  force  any  process  in  the  system  to  check  its  mailbox 
if  the  process  has  one  or  more  messages  that  have  been  in  the  mailbox 
for  a time  exceeding  the  preset  limit. 

When  a process  Z passes  the  validation  test  of  an  RBE  [Z.a:],  it 
needs  to  determine  whether  RBE  [Z.a:]  has  been  partially  validated  or 
completely  validated.  To  make  this  decision,  process  Z in  general 
needs  to  check  the  status  of  every  member  of  PR*([Z.a:])  (refer  to 
definition  DIO).  Therefore,  a process  must  know  not  only  the  PRS  but 
also  the  PR*  of  its  RBE  that  consists  of  both  the  PRS  and  the  IPRS 
(refer  to  definitions  D6  and  D8 ) . As  will  be  shown  in  section  3-3.2, 
the  IPRS  of  each  RBE  is  recorded  in  the  cache  store.  Whereas  a 
process  Z learns  of  its  new  potential  recallers  without  any  delay  and 
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its  table  PRST(Z)  as  well  as  its  record  of  the  PRS  of  each  RP  is 
always  up-to-date,  the  process  Z learns  of  new  indirect  potential 
recallers  of  its  RBE  [Z.a:]  with  some  delay.  This  is  because  process 
Z is  informed  of  new  indirect  potential  recallers  through  the  notices 
sent  by  other  processes.  To  be  more  specific,  when  RBE  [Y.e:],  a 
potential  recaller  of  RBE  [Z.a:],  has  been  partially  validated, 
process  Y identifies  all  the  members  of  PR#([Y.c:])  known  to  itself  by 
that  time  and  attaches  the  (possibly  incomplete)  information  on 
PR*([Y.c:])  to  a partial  validation  notice  (i.e.,  a notice  of  the 
success  of  validation  test  Y.d)  sent  to  process  Z.  Upon  receiving  the 
notice,  process  Z updates  not  only  its  record  of  the  status  of  [Y.c:] 
(kept  in  both  table  PRST(Z)  and  its  PRS  record  of  an  RP)  but  also  its 
record  of  IPRS([Z.a:])  kept  in  its  cache  store.  Since  information  on 
PR#([Z.a:])  is  not  collected  at  one  time,  a question  may  arise  as  to 
whether  there  is  danger  that  process  Z will  incorrectly  Judge  its  RBE 
to  have  been  completely  validated  while  there  is  an  on-going  RBE  of 
another  process  which  is  actually  a member  of  PR*([Z-a: ] ) but  not  yet 
known  to  process  Z.  The  following  lemma  settles  this  question  with  a 
proof  that  a process  always  judges  the  validation  status  of  its  RBEs 
correctly . 

Lemma : (L2)  The  members  of  PR*([Z.a:])  known  to  process  Z at  a 

particular  time  cannot  all  have  the  "partially  validated"  status  until 
all  the  members  of  PR*([Z.a:])  become  known  to  process  Z with  the 
"partially  validated"  status.  (Proof  in  Appendix  A) 

In  summary,  a process  accesses  a monitor  store  not  only  for  an 
update  of  or  a reference  to  the  shared  data  store  but  also  for 
updating  table  PRST(M)  and  putting  messages  in  mailboxes.  (The  latter 
accesses  are  transparent  to  the  program  designer.)  A prerequisite  for 
taking  any  of  these  actions  is  that  the  process  obtain  exclusive 
possession  of  the  monitor  and  ensure  that  its  mailbox  is  empty.  If 
the  mailbox  is  not  empty,  the  process  must  pick  up  all  the  messages 
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and  immediately  release  the  monitor.  A complete  procedure  (PI)  for 
message  Interpretation  which  follows  the  release  of  the  monitor  is 
described  in  Appendix  B. 

3.3-2  Cache  store  and  recovery  point  (RP)  management 

The  structure  of  a cache  store  (which  is  a part  of  a process 
store)  is  a tree  of  cache  segments  as  depicted  in  Figure  8b.  Figure 
8b  actually  corresponds  to  process  A in  Figure  8c.  A cache  segment 
roughly  corresponds  to  a region  of  a cache  stack  in  Figure  1b.  That 
is,  establishment  of  an  RP  r means  creation  of  a cache  segment  CS(r) 
while  discard  of  RP  r means  merging  of  CS(r)  into  its  immediate 
predecessor  cache  segment.  There  exists  a one-to-one  correspondence 
between  an  RP  and  a cache  segment;  in  implementation,  both  the  RP  and 
the  cache  segment  may  be  referred  to  by  the  same  identifier. 
(Furthermore,  an  RBE  may  be  represented  by  the  name  of  the  base  RP 
established  at  its  beginning  and  thus  each  potential  recaller  of  a 
process  or  a monitor  may  also  be  referred  to  by  a base  RP  name  in 
Implementation.)  The  terms  "base  cache  segments"  and  "branch  cache 
segments"  carry  meanings  analogous  to  base  ard  branch  RPs.  There  is  a 
table,  called  RP  directory,  in  which  an  entry  consists  of  an  RP 
name,  the  corresponding  instruction  address,  and  a pointer  to  the 
associated  cache  segment. 

The  tree  structure  represents  the  support  relation  among  RPs. 
For  example,  cache  segment  CS(A.6)  in  Figure  8b  is  linked  to  CS(A.l) 
because  RP  A. 6 is  supported  by  RP  A.1.  This  tree  structure 
facilitates  safe  reduction  of  RPs  by  the  rule  R3  if  the  number  of  RPs 
exceeds  a limit  determined  by  storage  space  available.  In  addition, 
since  this  tree  provides  information  on  the  relative  ages  of  the 
existing  RPs,  it  facilitates  locating  the  immediate  predecessor  of 
every  cache  segment  and  thereby  facilitates  merging  of  cache  segments. 
For  example,  if  RP  A. 6 is  to  be  discarded  in  Figure  3b,  the  immediate 
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Procell  A 


Figure  8b  A cache  store 

Figure  8c  A process  owning  the  cache  store  in  8b 


predecessor  of  CS(A.6)  is  found  to  be  CS(A.4)  from  the  tree  and  thus 
merging  of  CS(A.6)  into  CS(A.U)  takes  place. 

More  detail  on  a cache  segment  is  given  in  Figure  8d.  A cache 
segment  CS(r)  contains  a tree  linkage,  a base/branch  indicator,  either 
PRS(r)  if  RP  r is  a branch  RP  or  IPRS([r:])  if  RP  r is  a base  RP,  and 
variable  assignment  records  (already  shown  in  Figure  1b).  It  also 
contains  a "monitor  snapshot"  that  will  be  described  in  the  next 
section.  Figure  8d  also  shows  that  a special  record  which  is  a 
pointer  to  a region  which  has  been  separated  out  of  the  main  stack, 
may  be  contained  in  the  assignment  records  area.  To  illustrate  such  a 
situation,  note  that  cache  segment  CS(A.4)  is  used  from  A. 4 to  A. 6 (in 
Figure  8c).  A region  of  the  main  stack  that  corresponds  to  [:A.5]  is 
discarded  at  A. 5.  This  region  must  be  saved  in  CS(A.4)  because 
rollback  to  A. 4 includes  restoration  of  the  region  in  the  main  stack 
with  the  values  that  existed  at  A. 4.  This  example  also  points  out 
that  local  variables  of  RBE  [:A.5]  must  be  treated  as  non-local 

154 


- 


variables  from  A. 4 to  A. 5-  Therefore,  local  variables  of  RBE  [:A.5] 
can  be  restored  to  the  values  at  A. 4 by  relinking  the  region  saved  (at 
A. 5)  in  CS(A.4)  into  the  main  stack  and  then  undoing  the  assignments 
recorded  (between  A. 4 and  A. 5)  in  CS(A.4). 


Cache  Segment  CS(r) 


Figure  8d  A cache  segment 
3-4  Minimal  number  of  monitor  snapshots 

We  now  turn  to  the  problem  of  savin?  and  restoring  monitor 
states.  See  Figure  9a.  When  process  A fails  validation  teat  A.p  and 
rolls  back  to  A.1,  process  B rolls  back  to  B.4.  In  addition,  monitor 
M must  be  restored  to  the  state  that  existed  immediately  before  the 
first  update  A. 3 by  the  failed  RBE  [A.1:].  In  order  to  prepare  for 
this  monitor  restoration,  the  responsible  process  A must  record  the 
original  state  of  M before  it  modifies  M at  A. 3-  Unlike  the  main 
stack  of  a process  which  is  recorded  incrementally  by  making 
assignment  records,  the  recording  of  a monitor  state  is  performed  by 
creating  a snapshot  of  the  entire  shared  data  store  and  keeping  the 
snapshot  in  a cache  segment  of  a saving  process. 

Notation:  (N8)  A wavy  line  crossing  a shaded  column  which 

represents  the  state  history  of  a monitor  M,  represents  creating  a 
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snapshot  of  M by  a process. 


Procaa*  A Monitor  M Proceaa  B 


Figure  9a  Creation  of  a monitor  snapshot  (at  A. 3) 

On  the  other  hand,  there  is  no  need  for  a process  to  take  a 
snapshot  of  a monitor  at  the  beginning  of  a reference  to  the  monitor. 
To  illustrate  this,  if  process  B in  Figure  9a  failed  validation  test 
B.6  and  rolled  back  to  B.2  to  make  a retry,  process  A would  not  be 
aware  of  the  rollback  of  B.  Figure  9b  shows  such  a system  history. 
As  shown,  process  B makes  a monitor  reference  (B.4M  again  during  the 
retry.  If  monitor  operation  A. 5 were  a monitor  reference,  then  the 
monitor  state  referenced  at  B.4'  (during  the  retry)  would  be  identical 
to  the  state  referenced  at  B.4  (during  the  previous  unsuccessful  try). 
In  such  case,  creating  a snapshot  of  the  monitor  at  the  beginning  of 
monitor  reference  B.4  was  clearly  unnecessary.  If  A. 5 is  a monitor 
update  as  shown,  then  either  the  information  deposited  at  A. 5 is  not 
needed  for  reference  B.41  (or  B.4)  or  reference  B.4  was  executed 
incorrectly.  This  is  because  of  the  asynchronism  among  processes  in  a 
system  of  cooperating  parallel  processes.  Each  process  must  be 
designed  to  wait  in  a condition  queue  if  the  monitor  does  not  contain 
the  desired  information.  If  process  B should  have  waited  from  A. 4 
until  process  A supplied  the  desired  information  at  A. 5,  then  the 
monitor  will  contain  all  the  desired  information  at  reference  B.4' 
during  the  retry.  On  the  other  hand,  if  the  monitor  contained  all  the 
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I desired  information  at  B.4,  then  at  monitor  update  A. 5 process  A would 
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not  know  whether  process  B has  already  made  a reference  B.4  and  thus 
would  not  destroy  the  Information  desired  at  B.4  (unless  the  process  A 
is  faulty).  In  addition,  the  information  that  process  A supplies  at 
A. 5 will  not  be  needed  at  B.4'.  Thus  the  monitor  will  again  contain 
all  the  desired  information  at  B.4'.  Therefore,  a monitor  reference 
never  accompanies  a monitor  state  recording. 


Procej«  A Monitor  M Proceia  B 


Figure  9b  Monitor  reference  (B.4)  not  accompanying  a monitor  recording 

Mote  in  Figure  9a  that  monitor  update  A. 5 is  not  accompanied  by  a 
monitor  recording.  This  is  because  the  most  recently  established  base 
RP  is  A.1  and  process  A has  already  made  a monitor  update  along  with  a 
snapshot  before  A. 5.  In  other  words,  any  spontaneous  rollback  of 
process  A occurring  after  A. 5 will  be  made  to  base  RP  A.1  (or  to  an 
earlier  execution  point)  and  thus  will  Involve  restoration  of  the 
monitor  to  the  state  that  existed  before  the  first  update  A. 3 by  RBE 
[A.1:]  which  precedes  A. 5-  The  rule  for  recording  monitor  states  is 
stated  below. 

Rule-  (R4)  "Monitor  recording  rule":  A snapshot  of  a monitor 
must  be  taken  when  (and  only  when)  an  RBE  is  about  to  become  a 
potential  recaller  of  the  monitor  (at  a monitor  update).  Such  an 
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update  is  called  an  R-chalnlng  update. 


In  systems  using  one  monitor,  every  R-chaining  update  is  the 
first  update  made  by  a process  X during  its  RBE  [X.a:];  in  systems 
using  multiple  monitors,  an  update  which  is  not  the  first  to  be  made 
by  a process  during  its  RBE  can  be  an  R-chaining  update  as  will  be 
shown  in  section  4. 

Once  an  RBE  e is  completely  validated,  the  monitor  snapshots 
taken  at  monitor  updates  during  e may  be  discarded  unless  there  is 
another  on-going  or  partially  validated  RBE  f that  encloses  e and  had 
not  made  a monitor  update  before  e began.  For  example,  see  Figure  9c. 
When  validation  test  A. 7 succeeds  and  thus  RBE  [A. 4:]  is  completely 
validated,  the  monitor  snapshot  taken  at  A. 6 is  discarded  because  the 
enclosing  RBE  [A.1:]  already  made  a monitor  update  at  A. 3-  On  the 
other  hand,  the  monitor  snapshot  taken  at  B.12  can  not  be  discarded 
when  validation  test  B - 1 3 succeeds,  because  the  enclosing  RBE  [B.9:] 
had  not  made  a monitor  update  before  [B.11:]  began.  That  is,  merging 
of  cache  segment  CS(B.II)  into  CS(B.9)  should  involve  moving  the 
snapshot  taken  at  B.12  into  CS(B-9). 

3.5  Handling  of  wait  and  signal  instructions 

Assumption  A. 4 is  removed  now.  A monitor  procedure  may  involve 
one  or  more  executions  of  a wait  instruction  and  at  most  one  execution 
of  a signal  instruction  (at  the  end).  Condition  queues  are  now  a 
legitimate  part  of  the  shared  data  store;  they  must  be  included  in  a 
snapshot  and  in  a monitor  restoration.  Three  aspects  of  executing 
such  a procedure  which  are  not  present  when  executing  a monitor 
procedure  without  any  wait  or  signal  Instructions  are:  (1)  treating 
segments  of  a monitor  procedure  execution  as  atomic  (uninterruptible) 
monitor  operations  (with  respect  to  both  process  interaction  and  R- 
ehalning);  (2)  recalling  an  active  process  into  a condition  queue;  (3) 
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Figure  9c  A system  history 


notifying  a waiting  process  of  a rollback. 

First,  when  a process  executes  a monitor  procedure  that  has  wait 
and  signal  instructions,  it  generally  goes  through  an  alternating 
sequence  of  monitor-possessing  periods  and  waiting  periods  during 
which  it  does  not  possess  the  monitor.  Only  the  process  activity 
during  each  of  those  monitor-possessing  periods  is  uninterruptible  (by 
other  processes)  and  thus  is  an  atomic  monitor  operation.  As  before, 
an  atomic  monitor  operation  is  classified  as  a reference  operation,  an 
update  operation,  or  a reference-update  operation.  Since  it  is 
generally  impossible  to  predetermine  a sequence  of  atomic  monitor 
operations  involved  in  execution  of  such  a monitor  procedure,  a 
practical  approach  is  to  classify  the  monitor  procedure  as  a whole  and 
then  pass  that  classification  to  all  of  its  atomic  monitor  operations 
as  they  are  dynamically  defined.  Note  that  execution  of  a wait  or 
signal  instruction  should  be  treated  as  an  update  action  since  it 
changes  the  content  of  a condition  queue  that  is  a part  of  the  shared 
data  store.  Analogously,  when  a waiting  process  is  awakened,  the 
awaking  action  is  treated  as  a reference  action  since  the  awakened 
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process  received  information  (i.e.,  wakening  signal)  from  the 
signalling  process.  In  addition,  an  awakened  process  checks  its 
mailbox  first.  Thus  the  rule  that  obtaining  monitor  possession  and 
checking  a mailbox  form  an  inseparable  operation  still  holds. 

(N9)  A waiting  period  of  a process  is  represented  by  a discontinuity 
in  the  vertical  line  that  represents  the  progress  of  the  process. 

(N10)  An  undirected  horizontal  line  represents  a monitor  reference- 
u.adate  operation. 

For  example,  process  A in  Figure  10a  executes  a monitor  procedure 
(involving  wait  instructions)  from  A. 3 to  A. 8.  The  monitor  procedure 
execution  consists  of  three  atomic  monitor  reference-update  operations 
(A. 3,  A. 6,  and  A. 8).  Process  A is  in  a condition  queue  after  A. 3 
until  the  beginning  of  A. 6 (at  which  time  it  is  awakened  by  the  signal 
generated  by  B at  the  end  of  B.5),  and  again  after  A. 6 until  the 
beginning  of  A. 8.  Note  that  process  A establishes  an  RP  at  (the 
beginning  of)  A. 6.  Actually  a process  may  establish  multiple  RPs 
during  a single  monitor  procedure  execution  if  the  execution  Involves 
multiple  atomic  monitor  operations. 

Second,  restoration  of  the  monitor,  which  is  required  when  a 
process  rolls  back  to  an  RP,  may  include  recalling  some  processes  into 
the  condition  queues  in  which  the  processes  slept  previously.  For 
example,  assume  that  process  B in  Figure  10a  fails  validation  test  B.9 
and  needs  to  roll  back  to  E.4.  Process  B is  then  responsible  for 
restoring  the  monitor  to  the  state  that  was  recorded  at  monitor 
reference-update  B.5,  which  must  include  restoration  of  the  condition 
queue  that  contained  process  A.  Obviously  process  B can  not  restore 
the  queue  by  Itself  but  it  can  only  request  (by  mail)  process  A to 
roll  back  to  RP  A. 6 and  return  into  the  condition  queue.  When  process 
A has  returned  into  the  queue,  process  B must  detect  that  the  monitor 
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process  A Monitor  M process  B 


Figure  10a  A system  history  containing  waiting  periods  of  a process 
store  has  been  completely  restored  and  then  roll  back  to  B.4. 

To  implement  this  scheme,  a monitor  store  incorporates  the 
following  resources  transparent  to  the  program  designer:  a register 

DOOR,  two  single-position  condition  queues  MRP  and  RCPR,  and  two 
multiple-position  condition  queues  UNLOCK  and  PRTR.  (Here  names  MRP, 
RCPR,  and  PRTR  were  derived  from  "monitor-restoring  process", 
"recalled  process",  and  "processes  to  roll  back  out  of  monitor 
procedures",  respectively.)  When  DOOR  is  in  a "locked"  state,  the 
shared  data  store  can  not  be  accessed  by  any  process  except  the 
monitor-restoring  process  that  has  locked  the  store.  A process 
which  has  obtained  monitor  possession  checks  its  mailbox  but  if  it 
finds  the  shared  data  store  locked  when  it  accesses  the  store  to 
perform  an  operation  on  it,  then  the  process  will  execute 
"wait(UNLOCK) ".  Therefore,  queue  UNLOCK  keeps  a set  of  processes  that 
are  waiting  for  the  shared  data  store  to  be  unlocked.  Queue  MRP  is  a 
single-position  queue  in  which  the  monitor-restoring  process  that  has 
already  restored  the  shared  data  store  except  condition  queues  and 
locked  the  shared  data  store  may  be  waiting.  A process  which  has 
received  a return  request  (from  the  monitor-restoring  process)  returns 
into  special  queue  RCPR  and  then  the  monitor-restoring  process,  solely 
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capable  of  accessing  the  locked  shared  data  store  including  condition 
queues,  transfers  the  recalled  process  from  RCPR  to  the  destination 
condition  queue  w.  (The  name  of  the  queue  w is  obtained  from  the 
monitor  snapshot.) 

J For  example,  if  process  B in  Figure  10a  becomes  responsible  for 

restoring  the  monitor  to  the  state  that  existed  immediately  before 
B.5,  then  it  performs  the  following  in  sequence: 

(1)  restores  the  shared  data  store  except  for  the  condition  queues  by 
using  the  snapshot  taken  at  B.5; 

(2)  learns,  by  comparing  the  snapshot  with  the  current  state  of 
condition  queues,  that  process  A must  be  returned  into  a condition 
queue ; 

(3)  sets  DOOR  to  "locked",  thereby  locking  the  shared  data  store; 

(4)  puts  a recall  notice  "roll  back  to  RP  r and  return  to  special 
condition  queue  RCPR"  into  mailbox  MB( A) ; 

(5)  executes  "wait(MRP)"  (thereby  releasing  the  monitor). 

Therefore,  a process  which  has  received  a recall  notice  performs 
the  following  in  sequence: 

(1)  rolls  back  to  an  RP; 

(2)  obtains  the  monitor  possession; 

(3)  executes  a special  instruction  "signal(MRP)-and-wait(RCPR) " which 
causes  the  monitor-restoring  process  to  be  awakened  from  MRP  and  the 
recalled  process  itself  to  enter  RCPR. 

The  awakened  monitor-restoring  process  performs  the  following  in 
sequence • 

(1)  if  RCPR  is  not  empty,  transfers  the  recalled  process  in  RCPR  into 
the  destination  condition  queue  w,  where  w is  identified  from  the 
monitor  snapshot; 

(2)  checks  if  the  condition  queues  have  been  completely  restored  (by 
comparing  the  monitor  snapshot  with  the  current  state  of  the  queues); 
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(2.0  if  30,  unlocks  the  shared  data  store  by  changing  DOOR  into 
an  "open"  state,  executes  "signal(UNLOCK) " (thereby  releasing  the 
monitor),  and  rolls  back  to  an  RP  to  make  a retry; 

(2.2)  otherwise,  executes  "wait(MRP)". 

/ 

When  a process  is  ready  to  exit  from  a monitor  procedure  while 
the  shared  data  store  is  not  locked,  the  process  examines  programmer- 
transparent  queue  UNLOCK  and  if  it  is  not  empty,  executes 
"signal (UNLOCK) " or  else  simply  exits. 

Now  suppose  a process  X decides  to  restore  a monitor  to  a 
previous  state  first  and  then  to  roll  back  to  a base  RP  X.q.  Process 

X obtains  the  monitor  possession  and  checks  its  mailbox  as  usual.  If 

there  is  a recall  notice  from  process  Y asking  X to  roll  back  to  a 

branch  RP  X.r  and  return  into  special  queue  RCPR,  then  the  shared  data 

store  has  already  been  locked  by  process  Y and  thus  process  X compares 
base  RP  X.q  with  branch  RP  X.r.  If  branch  RP  X.r  was  established 
before  base  RP  X.q  then  process  X will  try  to  roll  back  to  RP  X.r  and 
enter  into  RCPR.  Otherwise,  process  X must  reestablish  the  shared 
data  store  to  a state  preceding  the  state  which  Y has  been  trying  to 
reestablish.  Process  Y is  now  asked  to  roll  back  to  the  RP 
established  when  it  became  R-chained  to  RP  X.q.  Therefore,  after 
learning  that  base  RP  X.q  was  established  before  branch  RP  X.r, 
process  X performs  the  following  in  sequence: 

(1)  obtains  the  monitor  possession; 

(2)  leaves  rollback  notices  into  appropriate  mailboxes  including  that 
of  process  Y; 

(3)  determines  whether  or  not  there  is  a process  that  X has  to  recall 
into  RCPR; 

(3-1)  if  there  is,  executes  "signal(MRP) " so  that  process  Y may 
be  awakened  to  receive  the  rollback  notice  while  process  X rolls  back 
to  an  RP  to  make  a retry; 

(3-2)  if  there  is  not,  executes  a special  instruction 
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"replace(MRP) " which  causes  the  process  Y In  queue  MT.P  to  be  replaced 
by  the  process  X executing  the  instruction.  As  a consequence,  process 
Y takes  possession  of  the  monitor.  Once  the  process  Y in  MRP  is 
awakened,  it  will  read  the  rollback  notice. 

Third,  restoration  of  a monitor  may  include  driving  processes  out 
of  some  condition  queues.  For  example,  assume  that  process  B in 
Figure  10b  has  failed  validation  test  B.p.  At  this  point  process  A is 
sleeping  in  a condition  queue  and  thus  will  not  check  its  mailbox 
unless  it  is  awakened.  Process  B should  therefore  waken  process  A so 
that  process  A may  read  the  rollback  notice.  The  programmer- 
transparent  multiple-position  queue  PRTR  in  a monitor  store  is  used  to 
buffer  the  processes  that  have  been  waiting  in  condition  queues  and 
need  to  be  awakened  to  read  rollback  notices.  When  an  RBE  e of 
process  X fails,  process  X accesses  monitor  store  MS(M)  and  examines 
RPQ(M,e) . Then  process  X performs  the  following  in  sequence: 

(1)  puts  rollback  notices  in  the  mailboxes  of  all  the  processes  that 
established  the  RPs  contained  in  the  RP  queue. 

(2)  moves  each  of  those  processes  that  established  RPs  contained  in 
the  RP  queue  and  have  been  sleeping  in  condition  queues,  into  special 
queue  PRTR  by  executing  a special  instruction  "move-to-PRTR(condition- 
queue-name) " ; 

(3)  locks  the  shared  data  store; 

(4)  executes  a special  instruction  "signal(PRTR)-and-wait(MRP)"  which 
causes  a process  Y at  the  front  of  queue  PRTR  to  be  awakened  while 
process  X enters  into  queue  MRP.  The  awakened  process  Y then  reads 
the  rollback  notice. 

The  actions  taken  by  a process  while  releasing  a monitor  without 
executing  a signal  instruction  are  summarized  as  follows. 

Procedure : (PI)  "Monitor  exit" 

(case  1)  DOOR  = "open": 


\ 

• -J 
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Figure  10b  A process  (A)  that  needs  to  be  driven  out  of  a queue 


If  UNLOCK  is  empty 

then  simply  release  the  monitor; 
else  execute  "signal (UNLOCK) " ; 
(case  2)  DOOR  = "locked": 
if  PRTR  Is  empty 

then  execute  "signal (MRP )" ; 
else  execute  "signal (PRTR) " ; 


Clearly  the  message  interpretation  procedure  Pb  (in  Appendix  B)  must 
now  be  extended  to  handle  the  situations  discussed  in  this  section. 
The  extended  version  will  not  be  detailed  in  this  paper. 

3-6  Indirect  recovery 

We  now  consider  the  case  in  which  a process  that  has  produced 
erroneous  information  for  other  processes  cannot  have  an  opportunity 
to  execute  its  own  validation  test.  The  system  would  crash  unless 
additional  features  have  been  incorporated.  In  Figure  11,  assume 
that  process  A stores  erroneous  information  into  the  monitor  store  at 
A. 3.  Process  B takes  the  erroneous  information  at  B.4  and 

subsequently  fails  the  validation  test  at  B.p.  A retry  by  process  B 
might  fall  again  at  B.p  since  the  erroneous  information  generated  at 
A. 3 is  still  in  the  monitor  and  is  referenced  again.  Meanwhile 
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process  A is  not  aware  of  the  failure(s)  of  process  B and  is  waiting 
inside  a condition  queue  for  a wakening  signal  that  has  to  be  supplied 
by  process  B (after  B.p)  but  has  not  been  produced  because  process  B 
has  not  passed  B.p.  In  a sense,  this  is  a deadlock  situation. 


Procasi  A Monitor  M Process  B 


Figure  11  A process  (A)  entering  a condition  queue  after 
depositing  bad  information 

If  process  B does  not  maintain  any  RP  earlier  than  B.1,  then 
process  B will  have  to  be  abandoned  after  the  unsuccessful  retries 
with  all  the  available  alternates  and  the  system  will  crash.  In  this 
case,  the  system  crashes  despite  the  possibility  that  validation  test 
of  RBE  [A. 2:]  may  be  able  to  detect  the  error  and  a retry  by  process 
A from  A. 2 may  circumvent  the  error.  That  is,  the  resources  in  the 
system  are  not  fully  utilized. 

There  are  two  possible  solutions  tc  this  problem.  One  is  to  make 
the  programmer-transparent  watchdog  process  (introduced  in  section 
3-3-1)  also  responsible  for  periodically  examining  the  status  of  every 
process  and,  upon  detection  of  a process  that  has  spent  an  excessive 
amount  of  time  in  a condition  queue,  forcing  the  process  to  roll  back 
to  the  immediately  preceding  base  RP  and  to  begin  a retry.  A process 
X that  has  exhausted  all  the  alternates  waits  (at  the  point  of  the 
last  failure)  until  another  process  Y that  interacted  with  X and  has 
slept  long,  is  forced  by  the  watchdog  process  to  roll  back.  Process  Y 
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sends  out  the  notice  of  this  rollback  and,  upon  (being  awakened  by  the 
watchdog  process  and)  receiving  the  notice,  process  X initiates 
another  retry.  The  other  solution  is  to  allow  S-propagation  as  a last 
resort  when  process  X has  exhausted  all  the  alternates  and  is  about  to  * 

be  abandoned.  That  is,  process  X requests  the  processes  that  have 
produced  information  which  was  referenced  by  X,  to  roll  back  to  their 
earlier  base  RPs,  and  thereafter  process  X makes  a retry.  This 
exception  (i.e.,  S-propagation)  can  be  Justified  since  the  system 
would  have  crashed  anyway.  However,  the  first  approach  of  relying 
upon  the  watchdog  process  may  allow  faster  recovery  in  many  cases. 

Either  way,  the  error  is  indirectly  detected  and  recovered. 

Suppose  now  that  process  B in  Figure  11  maintains  an  RP  B.O 
preceding  B.1  and  its  rollback  to  B.O  entails  the  rollback  of  process 
A to  RP  A. a preceding  A. 2 (through  R-propagation) . Assume,  as  before, 
that  process  A stores  erroneous  information  at  A. 3*  As  process  B 
repeatedly  fails  at  B.p  and  rolls  back  to  B.O  (once  every  n failures 
at  B.p,  where  n denotes  the  number  of  alternates  within  the  RB 

originally  entered  at  B.1),  process  A will  repeatedly  roll  back  to  A. a 

and  reenter  the  RB  originally  entered  at  A. 2.  Again  this  looping 

situation  cannot  be  circumvented  unless  process  A executes  a new 

alternate,  starting  at  A. 2.  Therefore,  it  is  desirable  for  a process 
to  try  a new  alternate  at  some  time  if  it  is  repeatedly  forced  to 
reenter  the  same  RB. 
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4 . Fault-tolerant  monitors  and  extended  recovery  caches  In  systems 
i containing  multiple  monitors 

This  section  discusses  the  problems  introduced  by  the  systems 
containing  more  than  one  monitor  and  solutions  to  those  problems. 
Systems  without  nested  monitors  are  considered  in  section  4.1  ana  Chen 
systems  with  nested  monitors  are  considered  in  section  4.2. 

4.1  Systems  containing  multiple  non-nested  monitors 

If  a process  can  access  multiple  monitors,  then  the  process  must 
in  general  maintain  snapshots  of  multiple  monitors  and  its  rollback 
may  involve  restoration  of  multiple  monitors.  Process  B in  Figure  12a 
Is  such  a process.  An  RBE  [B.a:]  of  process  B may  become  a potential 
recaller  of  both  Ml  and  M2  and  through  them,  a potential  recaller  of  A 
and  C.  The  extension  of  both  a faultrtolerant  monitor  and  an  extended 
recovery  cache  to  handle  this  is  obvious  and  thus  is  not  elaborated. 


Figure  12a  A system  of  three  processes  and  two  non-nested  monitors 

A less  obvious  problem  is  that  of  handling  a rollback  chain 
formed  through  multiple  monitors.  For  example,  a rollback  chain  may 
be  established  in  Figure  12b  which  connects  RBE  C A . 1 : ] of  process  A 
to  process  C (at  C.5)  through  three  other  system  components:  monitor 
Ml  (at  A. 2),  process  B (at  B . 3 ) , and  monitor  M2  (at  B.4).  In  that 
case,  rollback  of  process  A to  RP  A.1  will  require  rollback  of  process 
B to  RP  B.3  which  will  in  turn  require  rollback  of  process  C to  RP 
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C.5.  A natural  path  through  which  a rollback  notice  or  validation 
notice  is  sent  is  the  rollback  chain  itself.  Therefore,  when  process 
B is  about  to  excute  an  update  at  B.4  that  R-chains  RBE  [A.1:]  to  M2, 
it  must  detect  that  the  monitor  (Ml)  through  which  it  became  R-chained 
to  RBE  [A.1:]  is  different  from  the  monitor  (M2)  which  it  currently 
R-chains  the  RBE  to,  and  must  record  this  fact  in  cache  segment 
CS(B.3).  Process  B will  then  be  responsible  for  relaying  a rollback 
notice  or  validation  notice  (related  to  [A.1:])  to  the  processes  that 
may  become  R-chained  to  [A.1:]  through  M2.  If  process  B is  asked  to 
roll  back  to  B-3»  it  can  perform  the  following  in  sequence: 

(1)  finds  from  CS(B.3)  the  record  of  R-chaining  [A.1:]  to  M2; 

(2)  obtains  possession  of  M2  and  restores  the  shared  data  store; 

(3)  finds  RP  C.5  from  RPQ(M2 , [ A . 1 : ] ) and  puts  a rollback  notice  in  the 
mailbox  of  process  C; 

(4)  releases  M2  and  rolls  back  to  B.3. 


A Ml  8 M2.  C 


Figure  12b  A rollback  chain  connecting  five  system  components 


A notice  of  the  validation  of  [A.1:]  can  be  relayed  in  an 
analogous  manner.  In  short,  if  an  RBE  [X.a:]  of  a process  X has 
become  a potential  reoaller  of  a monitor  M through  ar.  update  by 
another  process  Y,  then  process  Y serves  as  a messenger  or  acting 
agent  of  RBE  [X.a:]. 
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In  systems  using  multiple  monitors,  the  function  of  a watchdog 
process  needs  to  be  extended  further.  To  see  the  need,  consider  a 
process  X waiting  in  a queue  within  monitor  store  MS(M2)  while  another 
process  Y puts  a recall  notice  in  the  mailbox  of  process  X within 
another  monitor  store  MS(M1)  and  enters  queue  MRP.  If  process  X is 
waiting  for  a wakening  signal  from  process  Y,  then  both  processes  are 
deadlocked  until  the  special  watchdog  process  intervenes.  The 
watchdog  process  now  has  to  waken  process  X from  the  condition  queue, 
and  then  force  it  to  release  M2  and  check  the  mailbox  MB(X,M1). 

4.2  Systems  containing  nested  monitors 

If  a monitor  procedure  p includes  calls  to  other  (nested)  monitor 
procedures,  then  execution  of  p is  treated  as  a compound  monitor 
operation  which  may  be  broken  into  several  atomic  operations  between 
which  RPs  may  be  established. 

Notation;  (N10)  A continuous  execution  of  a monitor  procedure 
including  calls  to  nested  monitor  procedures  is  represented  by  a 
vertically  shaded  horizontal  column. 

For  example,  consider  the  system  in  Figure  13a  of  which  a segment 
of  execution  history  is  depicted  in  Figure  13b.  Process  A executes  a 
monitor  procedure  that  belongs  to  Ml  and  involves  both  a reference  to 
and  an  update  of  Ml,  from  A. 3 to  A. 7.  Similarly,  process  C executes  a 
compound  monitor  operation  from  C.2  to  C.8.  On  the  other  hand,  the 
monitor  operation  C.9  is  an  atomic  monitor  operation  since  the  monitor 
procedure  (of  M2)  executed  does  not  involve  either  a call  to  M3  nor  an 
execution  of  wait  or  signal  instruction.  For  the  same  reason,  every 
execution  of  a procedure  of  M3  shown  in  the  figure  is  an  atomic 
monitor  operation.  RBE  [A.ls]  becomes  a potential  recaller  of  M3  at 
A. 4,  and  the  snapshot  of  M3  taken  at  this  time  is  appended  to  the 
snapshot  of  Ml  taken  at  A. 3-  Process  C then  becomes  R-chained  to  RP 


170 


r 


t 


i 


i 


A . 1 at  C.5  and  thus  an  RP  is  established.  This  RP  establishment 
involves  checkpointing  of  the  state  of  both  process  store  PS(C)  and 
monitor  store  MS(M2)  (i.e.,  creation  of  a cache  segment  in  PS(C)  and 
taking  a snapshot  of  MS(M2)). 


Figure  13a  A system  containing  a nested  monitor  M3 


A Ml  M3  M2.  C 


Figure  13b  A history  of  the  system  in  13a 


Given  that  taking  a snapshot  of  a nested  monitor  and 
establishment  of  an  RP  are  performed  as  mentioned  above,  another  area 
that  requires  an  extension  is  communication  of  rollback  notices  or 
validation  notices  among  processes.  A message  communication  scheme  is 
given  below. 
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First,  when  a process  in  possession  of  several  nested  monitors 
executes  wait(q)  to  enter  a condition  queue  q in  the  last  acquired 
monitor  Mn,  it  releases  only  Mn  but  it  maintains  the  possession  of 
other  earlier  acquired  monitors  while  sleeping  in  q.  Thus  a sleeping 
process  may  be  in  possession  of  some  monitors.  In  order  to  allow  the 
mall  kept  in  the  mailboxes  within  such  a monitor  (possessed  by  a 
sleeping  process)  to  reach  the  receiving  processes,  the  mailboxes  must 
be  accessible  to  any  process.  That  is,  a sleeping  process  does  not 
have  complete  exclusive  possession  of  such  a monitor  but  only  keeps 
the  shared  data  store  of  the  monitor  locked;  another  process  may 
acquire  the  monitor  Just  to  check  a mailbox,  find  the  shared  data 
store  locked,  and  thus  enter  the  queue  UNLOCK  (introduced  in  section 
3.5). 

Second,  a nested  monitor  maintains  mailboxes  only  for  system 
components  (i.e.,  processes  or  monitors)  that  have  direct  access 
capabilities  to  the  monitor.  For  example,  monitor  M3  in  Figure  13a 
maintains  mailboxes  only  for  two  monitors  Ml  and  M2. 

Third,  mail  addressed  to  a process  which  is  R-chained  to  a 
monitor  M is  forwarded  through  the  R-chain.  For  example,  if  process  C 
in  Figure  13a,  which  has  become  a potential  recaller  of  M3  through  M2, 
needs  to  send  a message  to  process  B which  is  R-chained  to  M3  through 
Ml , then  it  can  put  the  mail  addressed  to  process  B in  the  mailbox 
within  M3  maintained  for  Ml . In  a sense,  Ml  is  viewed  as  a cover 
of  process  A or  B when  either  process  accesses  M3  through  Ml.  This 
mall  can  reach  process  B in  two  ways.  First,  if  process  B accesses 
monitor  M3  through  Ml  before  process  A,  It  checks  the  mailbox  for  its 
cover  Ml.  Since  the  mailbox  is  not  empty,  process  B picks  up  the 
mail,  releases  M3,  and  then  opens  the  mail.  Process  B learns  that  the 
mail  is  addressed  to  itself  and  thus  releases  Ml  before  starting  the 
interpretation  of  the  mail.  In  the  other  case  where  process  A 
accesses  M3  through  Ml  before  process  B,  it  takes  the  mall  (addressed 
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to  B)  from  the  mailbox  within  M3  maintained  for  its  cover  Ml,  releases 
M3,  and  puts  the  mail  into  the  mailbox  MB(B,M1).  Process  A reaccesses 
M3  and  the  mail  will  then  be  read  later  when  process  B accesses  Ml. 
Therefore,  both  processes  A and  B are  responsible  for  checking  the 
mailbox  within  M3  maintained  for  their  common  cover  Ml . 

The  above  scheme  Implies:  when  a process  X in  an  RBE  that  is  a 
potential  recaller  of  a nested  monitor  M decides  to  send  a rollback  or 
validation  notice  to  another  process  Y that  is  R-chained  to  M,  process 
X must  know  the  R-chain  leading  to  Y.  Process  X must  use  the  R-chain 
as  the  destination  address  of  the  mail.  To  enable  this,  when  a 
process  becomes  R-chained  to  a nested  monitor  M and  establishes  a 
branch  RP,  the  name  of  the  RP  is  prefixed  by  the  name  of  the  cover  and 
then  the  prefixed  RP  name  is  inserted  into  the  RP  queue  attached  to 
table  PRST(M).  For  example,  when  process  C in  Figure  13b  becomes  R- 
chained  to  M3  at  C.5,  the  prefixed  RP  name  M2$C.5  is  inserted  into 
RPQ(M3 , [A. 1 : ] ) . If  a monitor  M is  a multi-level  nested  monitor,  then 
the  RP  name  will  be  prefixed  by  the  names  of  all  the  monitors  on  the 
R-chain  being  established. 
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Shared  resources  not  contained  within  a monitor 

Enclosing  some  shared  resources  within  a monitor  may  lead  to  an 
inefficient  system  because  of  the  rule  that  a monitor  may  have  no  more 
than  one  of  its  procedures  in  execution  at  a time.  Each  use  of  such  a 
resource  by  a process  generally  takes  a large  amount  of  time  and  thus 
there  is  strong  motivation  for  allowing  several  processes  to  use  the 
resource  simultaneously  as  long  as  there  is  no  danger.  For  example, 
it  is  sometimes  safe  to  allow  several  processes  to  simultaneously 
reference  the  same  sizable  record  (without  modification).  An 
efficient  design  would  then  provide  a monitor  in  which  processes,  one 
at  a time,  obtain  or  return  only  access  rights  to  a shared  resource 
while  the  shared  resource  itself  is  located  outside  the  monitor  and 
may  be  used  by  several  processes  possessing  access  rights  [H2]. 
Figure  14a  depicts  such  a design  and  Figure  14b  shows  a typical 
structure  of  a program  using  a shared  resource  associated  with  but 
located  outside  a monitor.  Program  structuring  in  the  form  shown  in- 
Figure  14b  is  not  a requirement,  however. 


A,B:  process 
M:  monitor 
SR:  shared  resource 


Figure  14a  A shared  resource  SR  associated  with  but  located 
outside  monitor  M 
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Figure  14b  Typical  program  structure  for  using  SR  in  14a 

We  assume  that  the  portions  (e.g.,  a statement  or  a block)  of  a 
program  that  uses  a shared  resource  outside  a monitor  can  be 
recognized  through  automated  analysis  of  the  program  text;  this  is  a 
prerequisite  for  applying  the  programmer-transparent  coordination 
approach  discussed  so  far  to  systems  containing  such  a shared 
resource.  A syntactic  unit  recognized  as  one  using  such  a shared 
resource  may  be  a statement!  a block  of  statements,  or  the  entire 
portion  between  the  monitor  procedure  call  for  obtaining  an  access 
right  and  the  other  for  returning  the  access  right  (depicted  in  Figure 
14b).  Execution  of  such  a syntactic  unit  is  treated  as  a unit 
operation  on  a shared  resource  and  may  involve  reference,  update,  or 
both;  it  is  analogous  to  the  execution  of  a monitor  procedure.  Once  a 
process  obtains  an  access  right  to  a shared  resource  SR,  it  may 
execute  many  unit  operations  on  SR  (each  involving  reference,  update, 
or  both)  before  returning  the  access  right.  Recovery  of  processes 
sharing  a resource  SR  outside  a monitor  can  be  facilitated  again  by 
maintaining  table  PRST(SR)  and  operating  mailboxes  for  the  processes 
that  may  access  SR,  in  a manner  similar  to  that  of  managing  table  PRST 
and  mailboxes  within  a monitor  store.  The  only  problem  is  the 
possibility  of  conflicts  among  several  processes  that  possess  access 
rights  to  SR  and  try  to  update  table  PRST(SR)  or  mailbox 
simultaneously . 
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A simple  and  natural  solution  is  to  enclose  table  PRST(SR) 
(together  with  the  attached  RP  queues),  mailboxes,  and  their 
management  procedures  within  a monitor,  called  recovery  monitor  (R_M)_ 
and  denoted  by  RM(SR).  This  recovery  monitor,  unlike  the  monitor  M in 
Figure  14b,  is  transparent  to  the  program  designer  and  can  be  provided 
by  the  processor  system  (in  cooperation  with  a parallel  program 
compiler).  Before  performing  a unit  operation  on  the  resource  SR,  a 
process  always  accesses  recovery  monitor  RM(SR)  to  examine  table 
PRST(SR).  Acquisition  of  recovery  monitor  RM(SR)  and  the  subsequent 
mail  check  form  a single  inseparable  operation  as  before.  Although 
multiple  processes  may  possess  access  rights  to  SR  simultaneously, 
they  can  become  potential  recallers  of  SR  or  become  R-chained  to  RBEs 
through  SR  one  at  a time  only. 

If  the  number  of  resources  shared  outside  a monitor  is  large, 
then  the  number  of  recovery  monitors  provided  will  also  be  large.  If 

a smaller  number  of  recovery  monitors  is  desired,  then  a recovery 

monitor  can  be  provided  for  and  associated  with  a group  of  shared 
resources  as  if  the  group  of  resources  were  a single  large  shared 

resource;  the  price  paid  is  the  increased  frequency  of  process 

synchronization  due  to  increased  access  to  the  same  recovery  monitor. 


6 . Summary 

Programmer-transparent  coordination  of  process  rollbacks  in 
systems  of  interacting  fault-tolerant  processes  is  a goal  pursued  in 
this  paper.  The  approach  explored  is  based  on  the  strategy  of 
prohibiting  rollback  propagation  due  to  suspicion,  in  keeping  with  the 
spirit  of  designing  processes  to  harmoniously  cooperate  with  one 
another.  An  important  requirement  that  any  practical  scheme  for 
automated  coordination  must  meet  is  the  maintenance  of  a manageable 
number  of  RPs  at  all  times.  Two  useful  rules  were  formulated  to  meet 

I 

the  requirement:  maintenance  of  minimal  RP  sets  based  on  PRSs,  and 
safe  discard  of  useful  RPs  under  practical  constraints  such  as  limited 
memory  space.  A monitor  mechanization,  termed  fault-tolerant  monitor, 
and  an  extension  of  recovery  cache  were  presented  to  demonstrate  the 
viability  of  the  automated  coordination  approach. 

. 

There  is  a trade-off  between  automated  coordination  approaches 
and  programmed  coordination  approaches.  Automated  coordination 
involves  greater  time  and  space  overhead  than  coordination  by  the 
program  designer.  On  the  other  hand,  rollback  coordination,  even  with 
the  help  of  language  tools  such  as  a conversation  [R1],  can  often 
become  an  unbearable  burden  on  the  program  designer.  This  limits 
programmed  coordination  to  being  practical  only  when  it  is  applied  at 
a relatively  macroscopic  level.  In  fact,  an  optimal  approach  in  some 
situations  may  be  a combination  of  programmed  coordination  and 
automated  coordination  approaches  such  that  the  program  designer  is 
concerned  only  with  coordination  at  a more  macroscopic  level  while 
coordination  at  a microscopic  level  is  automatically  handled  by  an 
intelligent  underlying  processor  system  equipped  with  fault-tolerant 
monitors  and  extended  recovery  caches.  Such  a combination  as  well  as 
evaluation  of  the  performance  of  an  intelligent  processor  system 
presented  in  this  paper  remains  as  a subject  for  future  study. 


References 


[Ml  Anderson,  T.  and  Kerr,  R.  , "Recovery  blocks  in  action:  a system 

supporting  high  reliability",  Proc . 2nd  Int 1 1 Conf  ■ QO  Software. 

EaKlneer.lii«>  1976,  pp. 447-457. 

[B1 ] Brinch  Hansen,  P. , "The  programming  language  Concurrent  Pascal", 
IEEE  Trans,  on  Software  Engr..  June  1975,  pp.  199-207. 

[Cl]  Chandy,  K.M.,  "A  survey  of  analytic  models  cf  rollback  and 
recovery  strategies",  Computer.  May  1975,  pp. MO-47. 

[DT]  Dahl,  0.,  Dijkstra,  E.D.,  and  Hoare,  C.A.R.,  Structured 

Programming.  Academic  Press,  1972. 

[D2]  Dijkstra,  E.W.,  "Hierarchical  ordering  of  sequential  processes", 
Acta  informatica.  Vol.1,  No. 2,  1971,  pp. 115-138. 

[HI]  Hecht , H. , "Fault-tolerant  software  for  spacecraft  applications", 
Tech.  Rept.  SAMSO-76-40,  Aerospace  Corp.,  Dec.  1975.  (also  in  [Y2]) 

x 

[H2]  Hcare,  C.A.R.,  "Monitors:  an  operating  system  structuring 

ooncept" , Comm,  of  ACM.  Oct.  1974,  pp. 549-557. 

[H3]  Horning,  J.J.,  Lauer,  H.C.,  Melliar-Smith , P.M.,  and  Randell,  B. , 
"A  program  structure  for  error  detection  and  recovery",  Lecture  Notes 
In  Comp . Sci . . vol . 16,  Springer-Verlag , 1974,  pp. 171-187. 

[K1]  Kim,  K.H.  and  Ramamoorthy,  C.V.,  "Recent  developments  in 
software  fault  tolerance  through  program  redundancy",  Proc.  10th 
Hawaii  Int  * 1 Conf,  on  System  Sciences.  Jan.  1977,  pp. 234-238. 


178 


/ 


[Ml]  Meyers,  M.N.,  Routt,  W.A.,  and  Yoder,  K.W.,  "Maintenance 
software",  Bell  System  Technical  Journal.  Special  Issue  on  No. 4 ESS, 
Sept.  1977,  pp. 1139-1167. 

[PI]  Parnas,  D.L.  and  Wurges,  H.  , "Response  to  undesired  events  in 

software  systems",  Proc.  2nd  Int’l  Conf. on  Soft-War's  Engineering. 

1976,  pp. 437-446. 

[ R 1 ] Randell , B. , "System  structure  for  software  fault  tolerance", 
IEEE  Trans,  on  Software  Enar.,  . June  1975,  pp. 220-232. 

[R2]  Repton,  C.S.,  "Reliability  assurance  for  System  250:  a reliable, 

real-time  control  system",  Proc.  Int’l  Computer COBNBPnlsatiP.D 

COAT..,  1972,  pp. 297-305. 

[R3]  Russell,  D.L.,  "Process  backup  in  producer-consumer  systems", 

Proc.  6th  Svmp-.  . on  Ooeratings  Systems ErinciBlfi.a,  Nov.  1977, 

pp. 151-157. 

[SI]  Shrivastava,  S.K.  and  Banatre,  J.P.,  "Reliable  resource 
allocation  between  unreliable  processes",  Tech.  Rept.  SRM/177, 
Computing  Lab.,  Univ.  of  Newcastle  upon  Tyne,  (to  be  published  in 

!£££.  Trana^-jan-S aCt wars.  Rnjglas  axing)  • 

[W1]  Wulf,  W.A.,  "Reliable  hardware-software  architecture",  IEEE 
lASLAii gp.  SpEtHarS-Ejagil,.,  June  1975,  pp. 233-240. 

[Y1]  Yau,  S.S.  and  Cheung,  R.C.,  "Design  of  self-checking  software", 
Lr.sc-. 1-2L75  Int  1 l_J.anL.  — on  . Bella&lg-Sflltwar-a.  pp-45o-457. 


[Y2]  Yeh,  R.T.  ed . , 'S&g&lal issue,  on  fault-tolerant  software’. 

Computing  Surveys.  Vol.8,  No. 4,  December  1976. 


Appendix  A:  Proofs  of  two  lemmas  stated  in  section  3 


Proof  of  t,  1 : To  each  current  potential  recaller  e of  a process 
there  corresponds  a valid  JtP  r established  by  the  process  when  RBE  c 
became  a potential  recaller  of  the  process.  The  RP  r is  obviously  the 
most  recent  valid  execution  point  of  the  process  when  RBE  e ha3 
failed.  On  the  other  hand,  to  each  RP  r currently  maintained  by  a 
process  there  correspond  one  or  more  current  potential  recallers  of 
the  process.  Since  the  process  needs  to  roll  back  when  and  only  when 
any  of  its  potential  recallers  fails,  the  process  maintains  no 
redundant  RPs.  Therefore,  processes  maintain  the  minimum  number  of 
RPs  required  to  make  every  rollback  with  minimum  distance.  Q.E.D. 

Proof  of  L2 : Suppose  that  the  members  of  PR*([Z.a:])  known  to 

process  Z at  time  t are  all  partially  validated  RBEs  while  there  is  an 
on-going  RBE  [X.e:]  belonging  to  PR*([Z.a:])  but  not  known  to  process 
Z.  Obviously  RBE  [X.e:]  is  an  indirect  potential  recaller  of  RBE 

[Z.a:l  and  thus  there  must  be  a sequence  of  RBEs  (e^.e.,, ,en^ 

where  e^  r [X.e:],  e()  = [Z.a:],  and  e^  (Hi<n)  is  a potential 
recaller  of  Suppose  ek,  where  1<k<n,  is  known  to  process  Z at  t 

while  is  not.  The  notice  of  the  partial  validation  of  ek  must 

have  included  information  on  the  then  known  members  of  PR*(ek)  that 
includes  e^_1  . in  addition,  when  process  Z received  the  notice,  it 
must  have  learned  both  the  fact  that  ek  had  been  partially  validated 
and  the  fact  that  e^  was  a member  of  PR*(ek).  Thus  every  e^  Ki<n, 
must  be  a member  of  PR#([Z.a:])  known  to  process  Z at  t.  This  means 
that  e1  (=  [X.e:])  is  an  on-going  RBE  known  to  process  Z,  in 

contradiction  to  the  assumption  made  at  the  beginning.  Q.E.D. 
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Appendix  H:  A message  interpretation  procedure  in  systems  using  one 
monitor  without  wait  or  signal  instructions 


Procedure : (Pb)  "Message  interpretation  (Y:  process;  M:  monitor)" 

(Intended-monitor-operation  = The  monitor  operation  that  process  Y would 
have  performed  if  the  mailbox,  that  contained  the  messages  currently 
being  interpreted,  had  been  empty) 

(Operation  A = a monitor  update  or  reference) 

(Operation  B = notification  of  a success  of  the  validation  test  of  [Y.c:]} 
(Operation  C = notification  of  the  discard  of  RBE  [Y.c:]) 

(Operation  D = notification  of  the  discard  of  a useful  base  RP) 

(Operation  E = notification  of  new  members  of  the  PR*  of  already 
partially  validated  RBE  [Y.c:]) 

(Message  1 = "RBE  [X.a:]  that  is  a potential  recaller  of  RP  Y.r  has  been 
completely  validated") 

(Message  2 = "RBE  [X.a:]  that  is  a potential  recaller  of  RP  Y.r  has  been 

partially  validated,  and  the  currently  known  PR*([X.a:])  is  "} 

(Message  3 = "RBE  [X.a:]  has  failed,  so  roli  back  to  RP  Y.r") 

(Message  *1  = "base  RP  X.J  has  become  a defunct  branch  of  base  RP  X.i  and 
RBE  [X.j:]  is  no  longer  a potential  recaller  of  RP  Y.r") 

(Message  5 = "RBE  [W.a:]  that  is  a previously  known  member  of  PR*([X.b:]), 
where  RBE  [X.b:]  is  a potential  recaller  of  RP  Y.r,  ha3  been 
partially  validated  and  the  new  members  of  PR*([X.b:])  are  ") 

sort  the  messages  in  the  chronological  order  of  the  RPs  mentioned  in 
the  messages; 

discard  the  messages  placed  after  the  first  message  of  type  Message  3 
in  the  sorted  list; 

starting  with  the  beginning  of  the  sorted  list,  interpret  each  message 
as  follows: 


4. 
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( case  1 ) Message  1 : 

(case  1.1)  Intended-monitor-operation  = A,  B,  D,  or  E: 

II  RP  Y.r  remains  then 

MEin 

remove  [X.a:]  from  table  PRST(Y)  and  the  record  of  PRS(Y.r); 

if  PRS(Y.r)  is  now  empty  then 

£e&in 

discard  RP  Y.r; 

If  discard  of  RP  Y.r  has  caused  a base  RP  Y.q  to  have  no 

branch  RPs  to  support  and  RBE  [Y.q:]  has  passed  its  vali- 
dation test,  then  RBE  [Y.q:]  ha3  become  completely  vali- 
dated, so  add  its  notification  to  the  list  of  intended 
monitor  operations  (i.e.,  operations  to  be  performed 
within  the  monitor  store) 

end 

-g-CUl; 

"continue"  (i.e.,  if  there  i3  another  message,  interpret  it; 
otherwise,  regain  the  monitor); 

(case  1.2)  Intended-monitor-operation  = C: 

1 f RP  Y.r  precedes  HP  Y.c 

then  do  the  same  as  in  (case  1.1) 
else  do  nothing  and  continue; 

(case  2)  Message  2: 

(case  2.1)  Intended-monitor-operation  = A,  B,  D,  or  E: 

update  the  status  of  [X.a:]  in  both  table  PRST(Y)  and  the 
record  of  PRS(Y.r); 

i f there  is  a base  RP  Y.q  supporting  RP  Y.r  then 

update  the  record  on  PR* ( [ Y . q : ] ) ; 

1 f RBE  [Y.q:]  has  been  partially  validated  and  all  the  members 
of  PR*([Y.q:])  now  have  the  "partially  validated"  status, 
then  RBE  [Y.q:]  has  become  completely  validated,  so 
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discard  base  RP  Y.q  and  the  branch  RPs  including  Y.r 
supported  by  Y.q; 

add  the  notification  of  the  decease  of  both  RBE  [Y.q:] 
and  other  RBEs  that  have  become  completely  validated 
together  with  [Y.q:],  to  the  list  of  intended 
monitor  operations 


end 

else  add  the  notification  of  the  new  members  of  PR* ([Y.q:] ) 
and  of  the  partial  validation  of  [X.a:]  to  the  list  of 
intended  monitor  operations 

snd; 

continue; 

(case  2.2)  Intended-monitor-operation  = C: 
if  RP  Y.r  precedes  RP  Y.c 

then  do  the  same  a3  in  (case  2.1) 
e l3e  do  nothing  and  continue; 

(case  3)  Message  3: 

abolish  the  list  of  intended  monitor  operations  and  roll  back  to  Y.r; 
(case  4)  Message  4: 

remove  RBE  [X.j:]  from  table  PRST(Y)  and  the  record  of  PRS(Y.r); 
continue; 

(case  5)  Message  5: 

(case  5-1)  Intended-monitor-operation  = A,  B,  D,  or  E: 

do  the  same  as  in  (case  2.1)  except  RBE  [W.a:]  substituting  for 
[X.a:]; 

(case  5-2)  Intended-monitor-operation  = C: 

1 f RP  Y.r  precedes  RP  Y.c 

then  do  the  same  a3  in  (case  5-1) 
else  do  nothing  and  continue; 

£n4=Pr.os^.dqre 


j 
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